Document de révocation v2, toujours nécessaire?

J’ouvre ce fil pour parler du document de révocation en v2.

Tickets liés :

  • #208 prendre en charge le document de révocation v1 sur duniter v2
  • #54 améliorer le document de révocation en ajoutant une limite temporelle

J’ajoute ci-dessous une discussion qui a eu lieu ailleurs.

D’une autre discussion

Je ne vois plus non plus l’intérêt des documents de révocation depuis qu’on met tout en place pour que le user note son mnemonic. Ça fait doublons de choses à sauvegarder, le parcours UX est suffisamment compliqué comme ça selon moi, mais j’imagine que c’est au choix de chaque client de mettre ça en avant ou non.

La propriété du document de révocation que n’a pas une méthode de dérivation de clé privée, c’est qu’on peut l’envoyer à des personnes de confiance.

Si ma maison brûle avec mon ordi et mon carnet en papier où est noté mon mnemonic, je peux demander à quelqu’un de révoquer mon identité. Si je meurs dans l’incendie, on peut encore révoquer mon identité.

Le document de révocation est donc toujours utile, même s’il est moins critique. Les clients pourraient toujours encourager à le sauvegarder, et à l’avenir, à l’envoyer à un certificateur (peut-être à la condition qu’il ait une date d’expiration).

Donc en effet si assez de précautions sont prises pour que mnemonic soit conservé, ça semble pertinent de ne plus rendre obligatoire le document de révocation.

1 Like

sauf erreur de ma part, aucun client n’implémente le fait de vérifier tous les X mois que l’utilisateur a bien noté son mnémonique ? Le fait de l’avoir noté à un instant T n’implique pas d’y avoit toujours accès à T+n.

Parce que je ne veux pas dégouter les gens avec des questions régulières sur son mnemonic.

Je préfèrerai implémenter du sharding au travers de sa toile de confiance, mais je n’ai pas eu le temps encore.

Comme ce n’est pas non plus le cas pour le document de révocation, si on trouve comment faire ça pour l’un on saura probablement le faire pour l’autre.

Les re-certificateurs peuvent jouer ce rôle.

Oui, je n’ai pas dit qu’il fallait le faire.

Je veux dire que si une utilisatrice n’a pas son doc de révocation ET qu’elle perd son mnemonic (le papier est perdu et le téléphone est cassé) ALORS elle n’a aucun moyen d’accéder à son compte membre ni de le révoquer.

Donc TANT QUE il n’y a pas de moyen fiable de récupérer le mnemonic (ou de vérifier que les utilisatrices l’ont effectivement noté quelque part accessible il y a moins de X mois), la sauvegarde du doc de révocation ne devrait pas être optionnelle.

1 Like

Pour avoir un peu de données pour éclairer ce débat, est-ce que quelqu’un aurait une idée de comment récupérer facilement l’ensemble des documents de révocations soumis en blockchain ? Si le document de révocation a été utilisé une dizaine de fois seulement, ça ne vaut peut-être pas la peine de mettre des efforts dessus en v2. S’il a été utilisé des centaines de fois, on peut essayer de contacter les gens pour voir le genre de situations qui a abouti à ça (est-ce qu’ils avaient perdu leur codes ou pas).

Dans l’archive json que j’utilise pour datajune, le champ "revoked": [], est toujours vide, et les identités révoquées se retrouvent dans "excluded", je ne sais pas comment les différencier.

PS

Je trouve un reliquat de code qui montre que j’avais un jour trouvé une manière de faire :

for rev in block["revoked"]
  pubkey = split(rev, ":")[1]            
  push!(revoked_pubkeys, (block["medianTime"], pubkey))
end

Mais là je ne vois tous les “revoked” vides.

2 Likes