Que sont les Decentralized Identifiers (DIDs) ?
Les identifiants décentralisés, généralement appelés DIDs, sont une manière d’identifier une personne, une organisation, un appareil, ou même un objet numérique sur Internet sans dépendre d’un fournisseur central unique. Au lieu d’avoir votre identité qui “vit” à l’intérieur d’une seule plateforme, un DID est conçu pour que vous (ou votre organisation) puissiez en garder le contrôle directement, généralement grâce à des clés cryptographiques.
Si vous vous êtes déjà dit : « je veux un identifiant qui fonctionne entre plusieurs systèmes, que je peux prouver contrôler, et qu’aucune entreprise ne peut désactiver », vous êtes très proche de l’idée centrale des DIDs.
Une définition simple
Un identifiant décentralisé (DID) est un identifiant unique qui peut être vérifié cryptographiquement et résolu vers un document décrivant comment interagir de manière sécurisée avec le propriétaire (ou sujet) du DID.
Un DID ressemble souvent à ceci :
did:method:some-unique-string
La partie du milieu, la “méthode”, est très importante, car elle indique aux systèmes comment le DID est créé, stocké et résolu.
Pourquoi les DIDs existent
Les identifiants traditionnels sont généralement émis et contrôlés par quelqu’un d’autre : une adresse e-mail est liée à un fournisseur de messagerie, un nom d’utilisateur est lié à une plateforme, de nombreuses “identités de connexion” dépendent de fournisseurs d’identité centralisés…
Cela peut très bien fonctionner, mais ces approches impliquent des compromis : verrouillage (lock-in), dépendance à une plateforme, et parfois un manque de portabilité.
Les DIDs ont été créés pour soutenir un modèle différent : une identité numérique vérifiable où le contrôle peut appartenir au propriétaire (ou contrôleur) du DID, plutôt qu’à un registre central ou à un fournisseur unique.
L’idée clé : un DID se résout vers un DID Document
Un DID n’est pas seulement une chaîne de caractères au hasard. Sa caractéristique la plus importante est qu’il peut être résolu en un document lisible par une machine, généralement appelé DID Document.
Un DID Document inclut généralement des éléments comme :
- Des méthodes de vérification (souvent des clés publiques) qui aident à prouver le contrôle du DID
- Des contrôleurs, c’est-à-dire qui est autorisé à mettre à jour le DID Document, selon la méthode
On peut le voir comme ceci :
- Le DID est l’identifiant que vous partagez.
- Le DID Document est ce que les autres systèmes récupèrent pour savoir comment vous vérifier et comment interagir avec vous.
Ce que “décentralisé” signifie vraiment ici
“Décentralisé” ne veut pas automatiquement dire “blockchain”.
Avec les DIDs, la décentralisation est rendue possible par les méthodes DID, et différentes méthodes s’appuient sur des infrastructures différentes. Par exemple :
- Certaines méthodes utilisent l’infrastructure du web (comme les domaines et HTTPS)
- Certaines méthodes sont basées sur des clés et n’ont pas besoin de registre
- Certaines méthodes utilisent des systèmes distribués (y compris des blockchains ou des registres similaires)
- Certaines méthodes sont conçues pour des relations peer to peer et des interactions privées
Le format DID est donc partagé, mais le système sous-jacent peut varier énormément.
Les méthodes DID, en termes simples
Une méthode DID est, en gros, le “livre de règles” qui définit comment un DID fonctionne.
Elle précise des choses comme :
- Comment le DID est créé
- Comment le DID Document est résolu (résolution)
- Comment les clés peuvent être renouvelées (rotation) ou mises à jour
- Comment le DID peut être désactivé
- Quelles sont les hypothèses de confiance et de gouvernance
Voici quelques exemples courants que vous verrez dans des projets réels :
did:web
Cette méthode relie un DID à un nom de domaine que vous contrôlez et utilise l’hébergement web standard et HTTPS pour publier le DID Document. Elle est populaire parce qu’elle est simple à déployer et facile à comprendre.
did:key
Cette méthode dérive le DID directement d’une clé publique, ce qui la rend très facile à générer et à utiliser. Elle est souvent employée dans des démos, des tests, et dans certains écosystèmes comme identifiant léger.
peer DIDs
Les peer DIDs sont conçus pour des relations privées, où vous pouvez vouloir un DID unique par connexion afin de réduire la corrélation et d’améliorer la confidentialité.
Il en existe beaucoup d’autres, et choisir la bonne méthode est une décision produit et sécurité, pas seulement un détail technique.
Comment les DIDs sont utilisés avec les Verifiable Credentials
Les DIDs sont couramment utilisés dans les écosystèmes de Verifiable Credentials (VCs).
Un flux typique ressemble à ceci :
- Un émetteur (issuer) émet un credential et le signe.
- Un détenteur (holder) le stocke et le présente plus tard.
- Un vérificateur (verifier) contrôle la signature et l’authenticité de l’émetteur.
- Une Status List peut indiquer si le credential a été révoqué ou non par son émetteur.
Où interviennent les DIDs ?
- L’émetteur peut être identifié par un DID.
- Le vérificateur peut résoudre ce DID pour récupérer les clés nécessaires à la vérification.
- Le détenteur peut aussi utiliser un DID pour s’identifier (preuve de possession), selon le cas d’usage et les objectifs de confidentialité.
C’est une des raisons pour lesquelles les DIDs sont si souvent discutés en même temps que les Verifiable Credentials (VCs) : ils permettent à la vérification de fonctionner entre organisations, sans obliger tout le monde à se regrouper sous une seule plateforme d’identité.
Cas d’usage réels courants
Les DIDs peuvent être utilisés pour :
- Des credentials éducatifs et professionnels (diplômes, certificats, licences)
- D’autres types de credentials, par exemple des pièces justificatives (banque, assurance, énergie, télécoms)
- L’identité d’une organisation pour la vérification inter-entreprises
- Les interactions “wallet vers service” dans des plateformes de credentials
- La messagerie sécurisée et la découverte (trouver les bonnes clés et les endpoints)
- L’identité des appareils et de l’IoT (où la gestion des identités à grande échelle est importante)
- Des cadres d’identité du secteur public qui ont besoin d’interopérabilité