DID expliqué : ce qu'est un identifiant décentralisé
Un identifiant décentralisé, presque toujours écrit DID, est un nom pour une partie que personne n'a besoin d'émettre et que personne ne peut retirer. C'est la réponse à une question que toute attestation numérique finit par rencontrer : le portefeuille contient une déclaration signée, alors qui l'a signée, et comment le vérifier sans écrire à celui qui tient le registre ?
Cette page en est la version en langage clair. Elle couvre de quoi un DID est composé, ce qui se passe quand on le résout, en quoi les méthodes courantes diffèrent et, tout aussi important, ce qu'un DID seul ne vous dit pas.
De quoi un DID est composé
Un DID est une ligne de texte en trois parties séparées par des deux-points. La première partie ne change jamais. La deuxième nomme la méthode, et la troisième est ce dont cette méthode a besoin pour trouver le bon document.
Cette partie centrale est la seule vraie décision. Tout ce que les gens ont en tête lorsqu'ils débattent des DID, où se trouvent les données, qui peut les modifier, ce que coûte leur maintien, est déterminé par la méthode et par rien d'autre.
did:web:credenco.com
did
Schéma
Toujours les mêmes trois lettres. Elles ne disent rien de plus que : ce qui suit est un identifiant décentralisé.
web
Méthode
Les règles pour trouver et mettre à jour le document. C'est le choix aux conséquences réelles, car il détermine qui doit garder l'identifiant accessible.
credenco.com
Identifiant propre à la méthode
La partie que seule cette méthode sait lire. Ici c'est un nom de domaine, ailleurs ce peut être une entrée de registre ou la clé publique elle-même.
Ce qui se passe lors d'une résolution
Seul, un DID ne fait rien. Sa valeur apparaît au moment où quelqu'un le résout : transforme la chaîne de caractères en le petit document qui se trouve derrière, lequel répertorie les clés publiques utilisées par son sujet et l'endroit où ce sujet peut être joint.
1. Vous avez un identifiant
Une attestation arrive en nommant la partie qui l'a signée. Pour l'instant ce n'est qu'une chaîne de caractères, et elle ne prouve rien.
2. Un résolveur lit la méthode
Le nom de la méthode indique au résolveur où aller : récupérer un fichier sur un domaine, lire un registre, ou extraire la clé de l'identifiant lui-même.
3. Un document revient
Il répertorie les clés publiques que le sujet utilise actuellement, et les points d'accès où il peut être joint.
4. Vous vérifiez la signature
Sans compte nulle part, sans clé d'API et sans demander la permission à celui qui exploite la méthode.
Pourquoi pas un nom de domaine ou un certificat
Le web dispose déjà de moyens de dire qui est quelqu'un, la vraie question est donc ce qu'un DID ajoute. Un nom de domaine indique où envoyer une requête, mais ne dit rien sur les clés appartenant à la partie qui se trouve derrière. Un certificat lie bien une clé à un nom, et le fait bien, mais seulement tant qu'une autorité le confirme et seulement pour la clé pour laquelle il a été délivré.
Une attestation a la fâcheuse habitude de survivre aux deux. Un diplôme reste un diplôme dans vingt ans, bien après que la clé de signature a été renouvelée et que le certificat qui la couvrait a expiré. Parce qu'un DID sépare le nom des clés, l'émetteur peut remplacer une clé sans que l'identifiant change et sans réémettre tout ce qu'il a déjà signé.
Les clés changent, le nom non
Renouveler une clé compromise revient à publier un nouveau document sous le même identifiant. Toute référence à l'émetteur reste valable.
Vérifier ne demande la permission de personne
Un vérificateur résout l'identifiant et vérifie les calculs. Il n'y a aucun compte à ouvrir chez l'émetteur et aucune limite de débit sur le service d'un tiers.
Les méthodes que vous rencontrerez vraiment
Bien plus d'une centaine de méthodes ont été enregistrées, et vous pouvez presque toutes les ignorer sans risque. Trois couvrent l'essentiel de ce que rencontre une organisation dans l'écosystème européen.
did:web
Le document est un fichier sur un domaine que vous contrôlez déjà. Rien de nouveau à exploiter et un coût d'entrée proche de zéro, ce qui explique pourquoi la plupart des organisations commencent là. Le revers : celui qui contrôle le domaine contrôle l'identifiant, et rien ne conserve ce que disait le document hier.
Lire la définitiondid:webvh
Le même fichier hébergé sur un domaine, plus un journal en ajout seul de chacune de ses versions passées. Un vérificateur peut constater que la clé à laquelle il se fie aujourd'hui y a été placée par la partie qui détenait l'identifiant hier, ce qui est précisément la faille laissée ouverte par did:web.
Lire la définitiondid:key
L'identifiant est la clé publique, encodée. Il n'y a rien à héberger ni à récupérer, ce qui la rend idéale pour des identités éphémères et jetables. Cela signifie aussi que la clé ne peut jamais être renouvelée, c'est donc le mauvais choix pour tout ce qui doit durer.
Les autres figurent dans le registre W3C des méthodes DID. Traitez une méthode qui n'y figure pas, ou que seul un produit prend en charge, comme une dépendance envers ce produit.
Ce qu'un DID ne vous dit pas
C'est là que la plupart des explications sur les DID s'arrêtent discrètement, et c'est pourtant la partie qui décide du succès d'un programme de portefeuille. Un DID prouve une continuité : la partie qui a signé cette attestation détient la même clé que celle qui a signé l'autre. Il ne prouve rien sur qui est cette partie dans le monde réel.
N'importe qui peut créer un DID en quelques secondes, y compris quelqu'un se faisant passer pour une université. Établir qu'un identifiant appartient réellement à un établissement accrédité est un travail distinct, réalisé par une liste de confiance, un certificat qualifié ou une attestation d'une partie à laquelle le vérificateur fait déjà confiance. Sous eIDAS 2.0, c'est exactement le rôle des listes de confiance et de l'enregistrement des parties utilisatrices.
Lues ensemble, les choses sont simples : le DID porte les clés, le cadre de confiance porte le sens, et un vérificateur a besoin des deux avant d'accepter quoi que ce soit.
Ce que cela signifie pour vous
Émetteur
Un seul identifiant qui survit à chaque rotation de clé, de sorte qu'une attestation signée il y a des années reste vérifiable et qu'une clé compromise devient une tâche d'exploitation plutôt qu'un rappel.
Vérificateur
Vous pouvez vérifier une signature sans compte, sans contrat et sans intégration par émetteur. Ce qu'il vous faut encore, c'est une liste de confiance indiquant quels identifiants accepter.
Titulaire du portefeuille
Rien à gérer. Les identifiants se trouvent dans vos attestations, et le portefeuille les résout pour vous lorsqu'il vous montre qui a émis quoi.
Termes associés
Questions fréquentes
Faut-il une blockchain pour utiliser des DID ?
Non. Cette association vient des méthodes construites en premier, pas de la norme. La spécification ne dit rien sur l'endroit où doit résider un document, et les méthodes utilisées au quotidien en Europe, did:web et did:webvh, sont toutes deux des fichiers servis en HTTPS ordinaire depuis un domaine que leur propriétaire possède déjà.
Pourquoi ne pas simplement utiliser un nom de domaine ?
Un domaine indique où trouver quelque chose, pas quelles clés lui appartiennent, et un certificat lie des clés à un nom aussi longtemps qu'une autorité le confirme. Un DID vous donne les deux à la fois et garde l'identifiant stable pendant que les clés derrière lui changent, ce qui rend une attestation signée il y a trois ans encore vérifiable aujourd'hui.
Quelle méthode devons-nous choisir ?
Partez de la durée pendant laquelle l'identifiant doit tenir et de qui a le droit de le modifier. Pour un émetteur dont les attestations survivent à ses clés, did:webvh donne aux vérificateurs l'historique nécessaire pour accorder confiance à une rotation. Pour des pilotes internes et des identités éphémères, did:web ou did:key suffit généralement, et changer plus tard reste une migration ordinaire plutôt qu'une refonte.
Un DID prouve-t-il qu'une organisation est bien celle qu'elle prétend être ?
Non, et le croire est l'erreur la plus courante. Un DID prouve que celui qui a signé deux choses détenait la même clé privée. Savoir si cette clé appartient à une université accréditée ou à quelqu'un qui a enregistré un domaine convaincant est une autre question, à laquelle répondent une liste de confiance, un certificat qualifié ou une attestation d'une partie en qui vous avez déjà confiance.
Sources
Cette page est informative et ne constitue pas un avis juridique. Consultez directement la spécification W3C pour la formulation faisant foi.