Blog · 28 juillet 2026

Comprendre les identifiants décentralisés (DID) du W3C (FR)

Explication technique de la spécification W3C DID Core : syntaxe des identifiants et des URL DID, sujets, contrôleurs, documents DID, méthodes, résolution, relations de vérification, services, confidentialité et informations.

Par Didit28 juillet 2026Mis à jour le 28 juil. 2026

La spécification W3C Decentralized Identifiers (DIDs) définit une syntaxe URI, un modèle de données commun, des documents DID, des propriétés fondamentales, des représentations, des exigences de méthode et des interfaces abstraites pour la résolution et la déréférencement d'URL DID. DID Core 1.0 est devenu une recommandation du W3C le 19 juillet 2022. DID Core 1.1 a été publié en tant que Snapshot de recommandation candidate le 5 mars 2026 ; il s'agit d'un travail plus récent à un stade de normalisation différent.

DID Core n'exige pas de blockchain, ne prouve pas l'identité légale d'une personne, ne stocke pas de justificatifs d'identité dans chaque document DID, et ne rend pas chaque point de terminaison résolu digne de confiance. Il normalise l'architecture de l'identifiant et du document. Une méthode DID distincte définit comment un DID particulier est créé, lu, mis à jour et désactivé sur l'infrastructure choisie.

Points clés à retenir

Un DID est un URI, pas un justificatif. Sa forme générique est did:<nom-méthode>:<identifiant-spécifique-à-la-méthode>.
Le sujet et le contrôleur sont des rôles différents. Le sujet est ce que le DID identifie ; le contrôleur est autorisé par la méthode à modifier le document DID.
Les clés nécessitent des objectifs explicites. Une méthode de vérification ne devient utilisable pour l'authentification, l'assertion, l'accord de clé, l'invocation de capacité ou la délégation que par la relation de vérification correspondante.
La méthode fournit les règles opérationnelles. DID Core est neutre sur le plan technologique ; la méthode définit l'interaction avec le registre, l'autorisation, la mise à jour, la désactivation et la résolution spécifique à la méthode.
La résolution ne crée pas de confiance par elle-même. Les implémenteurs doivent authentifier les résultats de la méthode, faire respecter le but de la preuve, gérer les clés et l'historique, protéger la confidentialité et appliquer la politique d'application.

Qu'est-ce qu'un identifiant décentralisé ?

Un identifiant décentralisé est un identifiant conçu de manière à ce que le contrôle puisse être établi sans qu'un fournisseur d'identité central ou une autorité de certification ne soit nécessaire pour émettre et maintenir chaque identifiant. Le mot « décentralisé » décrit la capacité de l'architecture à séparer le contrôle de l'identifiant d'un émetteur central unique ; il ne signifie pas que chaque implémentation est anonyme, publique, immuable ou stockée sur un grand livre distribué.

Un DID peut identifier :

une personne ;
une organisation ou un groupe ;
un appareil ou un objet physique ;
une ressource numérique ;
un modèle de données ;
un concept abstrait.

L'entité identifiée est le sujet DID. La chaîne seule ne révèle pas le type de sujet.

Syntaxe DID

La syntaxe générique est :

did:<nom-méthode>:<identifiant-spécifique-à-la-méthode>

Par exemple :

did:example:123456789abcdefghi

did est le schéma URI. example est le nom de la méthode DID. La chaîne restante est l'identifiant spécifique à la méthode. La spécification de la méthode définit la signification de cette valeur et la façon dont le logiciel la traite.

Un DID d'apparence valide n'est pas nécessairement utilisable. La méthode doit exister et le résolveur doit la prendre en charge.

URL DID : chemins, requêtes et fragments

Une URL DID commence par un DID et peut ajouter un chemin, une requête ou un fragment :

did:example:123456789abcdefghi/path?service=messages#key-1

Ces composants peuvent identifier ou aider à sélectionner :

une méthode de vérification à l'intérieur du document DID ;
une entrée de service ;
un autre fragment de document DID ;
une ressource accessible via un service ;
une version ou une option définie par la méthode.

Le fragment #key-1 identifie généralement une méthode de vérification. Cela ne signifie pas que la clé privée se trouve dans le document. Les documents DID publient des informations de vérification publiques ou des références ; les informations secrètes doivent rester protégées ailleurs.

L'architecture DID

Les concepts principaux sont liés mais non interchangeables :

Concept	Rôle
DID	Identifiant globalement unique conforme à la syntaxe DID
Sujet DID	Personne, organisation, chose, ressource ou concept identifié
Contrôleur DID	Entité autorisée par la méthode DID à modifier le document DID
Document DID	Données associées au sujet, y compris les méthodes de vérification et les services autorisés
Méthode DID	Spécification distincte pour la syntaxe et les opérations spécifiques à la méthode
Registre de données vérifiables	Infrastructure qu'une méthode utilise pour créer, lire, mettre à jour ou désactiver l'état DID
Résolveur DID	Logiciel ou matériel qui effectue la résolution DID pour les méthodes prises en charge
Déréférenceur d'URL DID	Logiciel ou matériel qui obtient une ressource identifiée par une URL DID

Sujet versus contrôleur

Le sujet et le contrôleur peuvent être la même entité, mais ce n'est pas obligatoire. Un parent pourrait contrôler un DID pour un enfant, une organisation pourrait contrôler un DID pour un appareil, ou plusieurs fiduciaires pourraient contrôler un arrangement de récupération.

Le contrôleur de niveau supérieur identifie un ou plusieurs contrôleurs DID. Le contrôleur requis d'une méthode de vérification identifie qui contrôle cette méthode ; ce n'est pas automatiquement le contrôleur DID de niveau supérieur. Les confondre peut accorder une autorité non intentionnelle.

Qu'est-ce qu'un document DID ?

Un document DID est l'ensemble des données associées à un sujet DID selon le modèle de données DID Core. Son id racine est le DID. Des propriétés de base facultatives peuvent décrire les contrôleurs, les identifiants alternatifs, les méthodes de vérification, les relations de vérification et les services.

Cet exemple simplifié utilise du matériel public de l'espace d'exemples de la spécification :

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ"
      }
    }
  ],
  "authentication": [
    "did:example:123#key-1"
  ],
  "assertionMethod": [
    "did:example:123#key-1"
  ]
}

did:example est réservé aux exemples ; les systèmes de production doivent utiliser une méthode réelle et ses exigences actuelles en matière de suite de méthodes de vérification. Le JSON ci-dessus est intentionnellement un JSON valide. De nombreux exemples imprimés dans les spécifications techniques contiennent des commentaires ou des ellipses pour la lisibilité et ne doivent pas être copiés directement dans un analyseur.

Propriétés fondamentales

id : le DID du sujet ; requis à la racine du document.
controller : un ou plusieurs DID autorisés à apporter des modifications selon la méthode.
alsoKnownAs : autres URI affirmés pour identifier le même sujet.
verificationMethod : mécanismes de vérification publics qui peuvent être référencés par des relations explicites.
authentication : méthodes autorisées pour l'authentification en tant que sujet.
assertionMethod : méthodes autorisées à exprimer des revendications, telles que l'émission de justificatifs d'identité.
keyAgreement : méthodes destinées à dériver du matériel secret partagé.
capabilityInvocation : méthodes autorisées à invoquer des capacités.
capabilityDelegation : méthodes autorisées à déléguer des capacités.
service : points de terminaison ou mécanismes d'interaction associés au sujet.

alsoKnownAs est une assertion, pas une preuve cryptographique que deux identifiants sont équivalents. Les applications doivent vérifier indépendamment la relation requise par leur modèle de confiance.

Modèle de données et représentations

DID Core définit un modèle de données abstrait et des règles pour la production et la consommation de représentations. Le modèle de données n'est pas identique à une sérialisation JSON.

Les exigences de représentation sont spécifiques à la version :

La recommandation DID Core 1.0 de 2022 définit application/did+json et application/did+ld+json. Sa représentation JSON-LD commence par le contexte de base https://www.w3.org/ns/did/v1.
La recommandation candidate DID Core 1.1 consolide le type de média de base en application/did. Sa représentation JSON-LD commence par https://www.w3.org/ns/did/v1.1.

Ne mélangez pas le type de média ou le contexte de base d'une version avec des revendications de conformité à l'autre. Fixez la version de la spécification que les producteurs et les consommateurs implémentent.

Les implémenteurs doivent négocier et valider la représentation explicitement. La signature d'octets JSON sérialisés arbitraires sans un mécanisme de canonisation et de sécurisation défini n'est pas équivalente au traitement correct du modèle de données DID.

Méthodes de vérification et relations de vérification

Une méthode de vérification décrit comment une preuve peut être vérifiée. Elle nécessite :

un id exprimé en tant qu'URL DID ;
un type ;
un controller ;
des informations de vérification appropriées à ce type.

Les informations publiques peuvent être représentées par une propriété définie telle que publicKeyJwk ou une autre forme autorisée par la suite de méthodes de vérification. Un JWK dans un document DID ne doit pas inclure d'informations de clé privée. Les mêmes informations de vérification ne doivent pas être dupliquées dans plusieurs propriétés de matériel au sein d'une même méthode.

La définition d'une méthode de vérification ne l'autorise pas à toutes les fins. L'autorisation provient des cinq relations de vérification explicites.

Relation	Objectif de preuve prévu
`authentication`	Authentification en tant que sujet DID par défi-réponse ou un autre mécanisme accepté
`assertionMethod`	Exprimer des revendications, y compris la signature d'un justificatif d'identité vérifiable où le mécanisme de sécurisation choisi l'utilise
`keyAgreement`	Établir du matériel cryptographique partagé, souvent pour le chiffrement
`capabilityInvocation`	Invoquer une capacité d'objet
`capabilityDelegation`	Déléguer une capacité d'objet

Un vérificateur doit vérifier la relation requise pour la preuve. Une clé listée uniquement sous authentication n'est pas automatiquement autorisée pour les assertions de justificatifs ou l'accord de clé.

Les relations peuvent intégrer une méthode de vérification complète ou en référencer une par URL DID. Les références améliorent la réutilisation mais nécessitent un déréférencement correct et une comparaison exacte des identifiants.

Services et points de terminaison de service

La propriété facultative service peut annoncer des moyens de communiquer ou d'interagir avec le sujet DID. Chaque entrée de service a :

un id unique ;
un type ;
un serviceEndpoint.

Le point de terminaison peut être un URI ou une autre structure autorisée. Les définitions de service sont extensibles, de sorte que les applications doivent comprendre le type choisi.

La publication d'un point de terminaison ne prouve pas que son serveur, son opérateur, son transport, son contenu ou sa destination est digne de confiance.

L'application doit authentifier l'état DID résolu par la méthode, valider le type de service, appliquer les contrôles de sécurité URL et réseau, et utiliser un protocole d'application avec ses propres propriétés de sécurité.

Les points de terminaison de service publics peuvent également créer une corrélation. La réutilisation d'un point de terminaison sur des DID par paire peut annuler l'avantage de confidentialité des identifiants séparés.

Ce qu'une méthode DID définit

DID Core fournit l'architecture commune. Une méthode DID conforme définit les règles spécifiques à la méthode nécessaires pour l'implémenter, y compris :

le nom de la méthode et la syntaxe de l'identifiant spécifique à la méthode ;
comment un DID et un document DID initial sont créés ;
comment l'état actuel est lu ;
comment les mises à jour autorisées sont soumises et vérifiées ;
comment un DID est désactivé ;
comment la résolution communique avec le registre ;
comment l'authenticité et l'intégrité des résultats sont établies ;
comment fonctionnent la rotation des clés, la récupération, le versionnement et l'historique ;
les considérations de sécurité et de confidentialité spécifiques à la méthode.

Le registre de données vérifiables pourrait être un grand livre distribué, un système de fichiers décentralisé, un réseau peer-to-peer, une base de données ou un autre système. L'architecture doit être évaluée sur la gouvernance, la disponibilité, l'autorisation, la confidentialité, le coût, l'historique et la résistance aux attaques plutôt que sur le mot « décentralisé ».

Critères de sélection de la méthode

Avant de sélectionner une méthode, testez :

la maturité et la gouvernance de la spécification ;
l'interopérabilité du résolveur et de la bibliothèque ;
l'autorisation de mise à jour et de désactivation ;
la rotation et la récupération des clés ;
la prise en charge de l'état historique ;
la confidentialité et la fuite de métadonnées ;
la disponibilité du registre et le risque de censure ;
les coûts de transaction ou d'exploitation ;
l'agilité cryptographique ;
la migration et l'échec de la méthode.

Changer de méthode signifie généralement introduire un nouvel identifiant et un chemin de migration fiable.

Résolution DID versus déréférencement d'URL DID

La résolution DID prend un DID et des options de résolution et renvoie :

les métadonnées de résolution DID ;
un document DID, un flux de documents ou aucun document ;
les métadonnées du document DID.

Le résolveur utilise l'opération « lire » définie par la méthode. DID Core définit des interfaces abstraites et des concepts de résultats communs ; la communication et l'authentification spécifiques à la méthode restent avec la méthode.

Le déréférencement d'URL DID prend une URL DID complète et renvoie :

les métadonnées de déréférencement ;
la ressource identifiée, si disponible ;
les métadonnées de contenu.

Le déréférencement peut d'abord résoudre le DID de base, puis sélectionner un fragment, un service ou une ressource externe. Ce n'est pas un synonyme de résolution.

La spécification W3C DID Resolution distincte développe des algorithmes détaillés de résolution et de déréférencement. Sa dernière publication est un W3C Working Draft daté du 24 juillet 2026, et le déréférencement d'URL DID est marqué comme une fonctionnalité à risque. Il reste un travail en cours de normalisation plutôt que de faire partie de la recommandation DID Core 1.0 de 2022, alors épinglez le brouillon avant de revendiquer la conformité.

Confiance et mise en cache du résolveur

Un résolveur est une frontière de sécurité et de confidentialité. Il voit les identifiants demandés et peut renvoyer un état obsolète ou manipulé. Évaluez :

la vérification des résultats de la méthode ;
l'authentification du transport et du résolveur ;
la fraîcheur et l'invalidation du cache ;
les options de version et de temps ;
la gestion des erreurs et le comportement de dégradation ;
la fuite de confidentialité par les recherches ;
le comportement en cas de défaillance du registre ou du réseau.

DIDs et justificatifs vérifiables

Les DIDs et les justificatifs vérifiables sont des spécifications complémentaires, pas le même objet.

Un DID de base peut identifier :

un émetteur de justificatif ;
un sujet de justificatif ;
un détenteur.

Une méthode de vérification utilisée par un mécanisme de sécurisation est plutôt identifiée par une URL DID, généralement un DID suivi d'un fragment tel que #key-1.

Le modèle de données W3C Verifiable Credentials 2.0 définit les justificatifs, les présentations, l'émetteur, le détenteur, le sujet, la validité, le statut, les schémas et les mécanismes de sécurisation. Il n'exige pas que chaque identifiant soit un DID.

Lorsqu'un DID est utilisé pour un émetteur, un vérificateur peut résoudre le DID de l'émetteur, localiser la méthode de vérification de la preuve et confirmer que la méthode est autorisée sous assertionMethod. Cette vérification cryptographique n'établit toujours pas :

que chaque revendication de justificatif est vraie ;
que l'émetteur est digne de confiance pour cette revendication ;
que le justificatif est actuel ou acceptable ;
que son statut, son schéma ou sa preuve répond à la politique ;
que le sujet du justificatif est la personne qui le présente.

Ces vérifications relèvent du mécanisme de sécurisation, du système de statut, du cadre de confiance, de la liaison de présentation et de la politique du tiers de confiance.

Considérations de confidentialité et de sécurité

Éviter les données personnelles dans les documents publics

Les documents DID peuvent être largement répliqués. Ne publiez pas de noms, d'identifiants gouvernementaux, de données biométriques, de justificatifs ou d'autres données personnelles simplement parce que le modèle est extensible. Le chiffrement n'est pas une solution durable pour les textes chiffrés publiquement de manière permanente.

Prévenir la corrélation

Les DID par paire ou spécifiques au contexte ne peuvent réduire la corrélation que si d'autres données sont également séparées. Les clés réutilisées, les points de terminaison de service, les identifiants réseau, les attributs de justificatifs, le timing et l'activité du registre peuvent lier des DID censés être séparés.

Rotation et récupération des clés

Planifiez le compromis avant le lancement. Définissez l'autorisation de mise à jour, les contrôleurs de récupération, les règles de seuil, la rotation, la gestion des anciennes clés et la désactivation. L'autorité de récupération nécessite une séparation et un audit.

Valider le but de la preuve

Vérifiez non seulement qu'une signature est valide, mais aussi que la méthode de vérification était autorisée pour la relation requise au moment pertinent. Empêchez la substitution entre les utilisations d'authentification, d'assertion, d'accord et de capacité.

Gérer l'historique avec soin

Un document DID actuel peut ne plus contenir une ancienne clé. La vérification d'une preuve historique peut nécessiter une version historique prise en charge par la méthode et une preuve fiable du moment de la preuve. « Clé non présente maintenant » et « preuve jamais valide » ne sont pas des conclusions équivalentes.

Erreurs courantes d'implémentation DID

Appeler DID Core une spécification de blockchain

DID Core est neutre sur le plan technologique. Les blockchains sont une architecture de registre possible.

Traiter le DID comme une preuve d'identité légale

Un DID prend en charge le contrôle des identifiants et la vérification cryptographique. La liaison d'identité réelle nécessite des preuves distinctes, des assertions d'émetteur ou un cadre de confiance.

Utiliser n'importe quelle clé listée à n'importe quelle fin

Faites respecter la relation de vérification explicite et le but de la preuve.

Faire confiance automatiquement aux points de terminaison de service

Validez l'état de la méthode et appliquez la sécurité au niveau de l'application, du transport, de l'URL et du contenu.

Supposer que tous les DIDs sont privés ou anonymes

L'activité du registre, la résolution, le matériel réutilisé et les services peuvent exposer une corrélation durable.

Une liste de contrôle d'implémentation

Avant la production, confirmez que :

les spécifications de la version de DID Core et de la méthode DID sélectionnées sont fixées ;
l'analyse des identifiants et des URL DID utilise une gestion URI conforme aux normes ;
les représentations et les types de médias acceptés sont explicites ;
chaque preuve applique la relation de vérification prévue ;
les résultats de la méthode sont authentifiés plutôt que fiables de n'importe quel résolveur ;
la mise en cache, le versionnement, la vérification historique et la désactivation sont testés ;
la mise à jour, la rotation, le compromis, la récupération et la migration ont des procédures répétées ;
les documents publics ne contiennent pas de données personnelles ou corrélées inutiles ;
les points de terminaison de service font l'objet d'un examen de sécurité distinct au niveau de l'application ;
la confiance, le statut, le schéma et les vérifications de présentation des justificatifs vérifiables restent séparés.

Là où les DIDs rencontrent la vérification d'identité

Les DIDs peuvent identifier des sujets et des informations de vérification, mais ils n'effectuent pas de preuve d'identité. Un système d'identité réutilisable a toujours besoin de preuves fiables et d'une décision gouvernée avant d'émettre ou d'accepter des revendications. La vérification d'identité de Didit peut fournir des preuves d'identité pour une telle décision, tandis que le KYC réutilisable prend en charge la réutilisation d'une vérification antérieure sur les services participants et est répertorié comme gratuit.

Cette adjacence de produits n'implique pas que chaque vérification Didit est un DID ou que la résolution DID remplace le KYC. Les tarifs actuels des modules sont disponibles sur la page de tarification. L'architecture doit maintenir le contrôle des identifiants, les preuves d'identité, l'émission des justificatifs, la présentation et la politique du tiers de confiance comme des limites de confiance distinctes.

Foire aux questions

Que définit la spécification W3C DID ?

Elle définit la syntaxe DID et URL DID, un modèle de données commun, les propriétés fondamentales des documents DID, les représentations, les exigences de méthode et les interfaces abstraites de résolution et de déréférencement.

Chaque DID utilise-t-il une blockchain ?

Non. Une méthode DID peut utiliser un registre, une base de données, un système peer-to-peer, un système de fichiers décentralisé ou une autre architecture de registre.

Quelle est la différence entre un DID et un document DID ?

Le DID est l'identifiant. Le document DID est un ensemble de données associées qui peut décrire les contrôleurs, les méthodes de vérification et leurs objectifs, les services et d'autres propriétés définies.

Quelle est la différence entre la résolution et le déréférencement ?

La résolution obtient un document DID et des métadonnées pour un DID. Le déréférencement obtient la ressource identifiée par une URL DID complète, potentiellement après avoir résolu son DID de base.

Un DID est-il identique à un justificatif vérifiable ?

Non. Un DID est un identifiant. Un justificatif vérifiable est un ensemble de revendications infalsifiables et vérifiables par machine selon le modèle de données VC et un mécanisme de sécurisation. Les VCs peuvent utiliser des DIDs mais ne les exigent pas universellement.

Le contrôle d'un DID prouve-t-il qui est une personne ?

Non. Il peut prouver le contrôle de l'autorité cryptographique ou spécifique à la méthode associée au DID. La liaison de ce contrôle à une identité légale ou réelle nécessite des preuves supplémentaires ou des assertions fiables.

Un document DID peut-il contenir des clés privées ?

Non. Les documents DID contiennent des informations de vérification publiques ou des références. Le matériel de clé privée ne doit pas apparaître et doit rester protégé par le système de gestion des clés du contrôleur.

Références principales

DID Core est plus utile lorsque sa revendication reste précise. Il normalise les identifiants, les documents, les objectifs de vérification, les services et les interfaces de méthode. La confiance provient toujours de la gouvernance de la méthode, de la résolution authentifiée, des clés protégées, du but explicite de la preuve, de la conception respectueuse de la vie privée et de la décision de l'application quant aux preuves à accepter.

Continue ta lecture