À regarder de plus prêt :
https://w3c.github.io/did-core/
Le but est de pouvoir obtenir et vérifier une identité après d’un DID controller garantissant la validité de l’identité. En connaissant le fournisseur d’identité, on peut accepter (ou pas) ça validité.
Je trouve le concept intéressant pour Duniter. On pourrait d’identifier sur un nœud, et accéder à d’autres services avec le DID.
J’ai lu en diagonale, à creuser…
Ça n’a pas l’air de garantir l’unicité d’un individu.
C’est conçu pour protéger ses données personnelles, pas pour détecter des doubles-comptes.
Les DID serait très pertinent en remplacement des profils Cesium+ par exemple, chaque utilisateur pouvant alors contrôler les données qu’il partage, a qui et dans quelles conditions.
En fait, la clé publique Ğ1 pourrait être un champ de donnée du DID, permettant de prouver à un service qu’on est membre de la Ğ1.
Ça viendrait donc plutôt autour, au niveau des services « branchés » à la Ğ1.
La toile de confiance reste indispensable, mais ne devrait pas stocker de données personnelles. Pour l’instant la seule donnée personnelle stockée est le UserID duniter, mais ce UserID ne sert à rien, on pourrait le supprimer.
Le seul argument pour garder le UserID duniter c’était la possibilité de pouvoir changer Ed25519 par un autre algo, mais je me rends compte que cet argument ne tient pas, la clé privée Ed25519 peut signer la clé publique du nouvel algo pour faire le lien.
En plus ce UserID génère des confusions, car il rentre en conflit avec le pseudo Cesium+. Je crois qu’il est grand temps de le supprimer.
La toile de confiance ne stockera alors plus que des certifications entre clés publiques, sans qu’un observateur extérieur puisse savoir qui est derrière une clé publique, sauf si la personne décide de dévoiler publiquement le lien entre sa clé publique et d’autres informations sur elle.