L’identité décentralisée sépare l’identification, l’émission, le stockage et la vérification des attestations afin qu’aucun fournisseur de connexion ne reste le gardien permanent de chaque interaction. Les decentralized identifiers, ou DID, aident une entité à prouver le contrôle d’un identifiant, tandis que les verifiable credentials, ou VC, portent des affirmations signées par un émetteur. Le bon modèle mental ne décrit pas une identité magique détenue par un portefeuille, mais un flux de confiance : l’issuer formule une affirmation, le holder la conserve et la présente, et le verifier contrôle la preuve, le statut, le contexte et la politique. Cet article explique ce flux, montre où la blockchain s’insère et pourquoi gestion des clés, révocation, divulgation sélective et protection des données restent indispensables.
Ce que signifie decentralized identity explained
L’expression decentralized identity explained se comprend plus facilement lorsque l’identité est découpée en couches. Un DID est un identifiant qui peut être résolu, via un DID method, vers un DID document ou une ressource associée. Ce document peut décrire des méthodes de vérification, des services et les relations pour lesquelles une clé peut être utilisée. Un VC est autre chose : un ensemble d’affirmations qu’un émetteur formule au sujet d’un subject, emballées pour qu’un verifier contrôle la paternité et l’intégrité. Un DID peut désigner une personne, une organisation, un appareil ou un service, mais seul il ne prouve ni l’âge, ni les études, ni l’emploi, ni le statut juridique.
Cette séparation évite une exagération courante. Décentralisé ne veut pas dire anonyme, introuvable ou hors du champ de la régulation. Un credential peut être solidement rattaché à une procédure réelle de vérification d’identité, et l’on peut toujours exiger du verifier qu’il applique ses propres règles d’éligibilité, de fraude, de sanctions ou d’accès. Un DID method peut aussi dépendre d’un service centralisé, d’un système fédéré, d’une base de données, d’un registre distribué ou d’un autre registry. La question de conception reste : qui contrôle l’identifiant, qui formule le claim, qui peut mettre à jour les clés associées et quelle partie peut se fier au résultat.
DID, issuer, holder et verifier dans un flux de confiance
Les quatre termes décrivent des rôles différents. L’issuer est l’autorité ou l’organisation qui affirme un fait et crée un credential. Le holder détient le credential, le plus souvent dans un wallet ou un autre dépôt protégé, et décide du moment de le présenter. Le verifier reçoit un credential ou une verifiable presentation et contrôle le mécanisme de protection, l’issuer, le subject, la période de validité, le statut et la finalité métier de la demande. Le subject est l’entité que l’affirmation concerne. Holder et subject sont souvent la même personne, mais un parent peut détenir un credential portant sur un enfant, ou une organisation des credentials portant sur un appareil.
Un DID document peut aider le verifier à découvrir le matériel public de vérification associé à un issuer ou à un holder. Les preuves Data Integrity peuvent lier une preuve à une méthode de vérification et à une finalité déclarée, mais une signature correctement contrôlée n’équivaut pas à accepter chaque affirmation. Le verifier doit encore prendre une décision de confiance : cet issuer est-il reconnu pour ce type d’affirmation, le schéma du credential convient-il, la présentation est-elle récente et la divulgation demandée est-elle proportionnée ? Le NIST décrit cela comme la séparation entre la vérification cryptographique et la validation puis l’évaluation des affirmations.
Le cycle de vie du VC, du proofing à la présentation
Le cycle de vie commence avant la cryptographie. Lors de l’enrôlement ou du proofing d’identité, l’issuer décide quelles preuves suffisent et quel niveau d’assurance le cas d’usage exige. Il crée ensuite des affirmations sur un subject, ajoute des métadonnées comme le type et la validité, puis protège le credential avec un mécanisme compatible. Le wallet ou le dépôt protège la copie du holder. Au moment de la présentation, le holder crée une presentation destinée à un verifier précis, en utilisant un credential ou un ensemble de credentials et en ne divulguant parfois que certaines affirmations.
La vérification est une séquence, pas une simple coche verte. Le verifier analyse le document, contrôle le modèle de données et le mécanisme de protection, résout le matériel de vérification pertinent, valide la finalité de la preuve et tout lien avec le holder, vérifie la période de validité du credential et effectue un contrôle de statut si un mécanisme existe ou si la politique l’impose. Il évalue seulement ensuite si l’issuer et les affirmations satisfont la règle métier. Un credential peut être cryptographiquement authentique et échouer quand même parce qu’il a expiré, qu’il est révoqué, qu’il vient d’une autorité non fiable, qu’il vise le mauvais subject ou qu’il ne convient pas à la finalité demandée. Renouvellement, mise à jour, suspension, révocation et suppression sont des événements du cycle de vie, non des propriétés qu’une blockchain gère automatiquement.
Keys, DID documents et revocation sont des contrôles distincts
Les clés privées ou secrètes sont l’autorité de signature. Une clé publique ou une autre méthode de vérification permet au verifier de tester une preuve, mais ne lui permet pas d’en créer une nouvelle valide. L’issuer doit protéger ses clés de signature, définir quelle relation de vérification chaque clé prend en charge, surveiller les compromissions et disposer d’un plan de rotation et de récupération. Le holder a aussi besoin d’un accès sécurisé à l’appareil, de sauvegarde ou de récupération et d’un moyen de distinguer une présentation de credential d’une demande de secret du wallet. Perdre une clé peut couper l’accès ; exposer une clé secrète autorise l’usurpation jusqu’à ce que l’écosystème la détecte et réagisse.
Trois horloges ne doivent pas être confondues. Une preuve peut porter des dates de création et d’expiration, un credential peut porter validFrom et validUntil, et une verification method peut être remplacée, révoquée ou laissée expirer parce que sa clé est compromise. Le credential status est un signal distinct : il peut indiquer que le droit ou l’affirmation représenté par un credential n’est plus d’actualité. Le verifier doit donc contrôler le mécanisme de statut et sa fraîcheur, et pas seulement la validité mathématique d’une signature. Listes de statut, registres ou points de terminaison de l’émetteur améliorent le contrôle opérationnel, mais réclament aussi des garanties de disponibilité, de confidentialité, d’intégrité et de gouvernance.
Selective disclosure et limite de la minimisation des données
La divulgation sélective signifie que le holder peut décider finement quelles informations partager. Si un service a seulement besoin de savoir si une personne dépasse un seuil, la date de naissance complète peut être inutile. Une presentation peut parfois porter une affirmation abstraite ou une preuve à divulgation nulle plutôt que l’attribut d’origine. D’autres profils utilisent des jetons de divulgation sélective ou des suites de preuves. La propriété exacte de confidentialité dépend du format du credential, de la suite cryptographique, du wallet, de la demande du verifier et de la possibilité de relier des présentations répétées.
La limite importante : DID et VC n’apportent pas automatiquement la confidentialité. Un identifiant stable, une signature répétée, une requête de statut, un événement de télémétrie du wallet ou une entrée de registre public peuvent créer une corrélation. La minimisation commence donc par la question du verifier : quelle est la plus petite affirmation utile à cette décision, pour combien de temps et qui doit la voir ? Les concepteurs devraient éviter de placer des données personnelles dans un registre public immuable, préférer des identifiants par paire ou adaptés au contexte si possible, réduire la conservation, protéger les journaux et faire comprendre à l’utilisateur la partie et la finalité avant tout partage. La confidentialité résulte de l’architecture, pas d’une étiquette sur un wallet.
Où la blockchain s’insère dans self sovereign identity blockchain
L’expression self sovereign identity blockchain laisse souvent entendre que chaque enregistrement d’identité doit se trouver on-chain. DID Core ne l’exige pas. Un DID method définit comment les identifiants et leurs documents sont créés, résolus, mis à jour ou désactivés, et un verifiable data registry peut être un registre distribué, une base de données, un système de fichiers décentralisé ou un autre système de confiance. La blockchain peut servir de registre public et infalsifiable des opérations de méthode, des métadonnées de confiance des issuers, des événements de rotation de clés ou d’informations de statut compactes. Elle facilite aussi la découverte partagée quand les participants refusent qu’un seul opérateur contrôle le registre.
La blockchain apporte aussi coûts et risques. Les données publiques se copient, se corrèlent et s’effacent mal ; disponibilité des transactions et gouvernance peuvent changer ; un hash ne prouve pas l’exactitude de la donnée d’origine ; un ancrage immuable ne répare pas une clé d’issuer compromise. Une conception saine garde affirmations personnelles et documents volumineux dans un stockage protégé adapté, ne publie que les données de registre nécessaires et documente le fonctionnement des mises à jour, de la récupération, de la migration et des demandes légales. Le contrôle auto-souverain se comprend mieux comme un ensemble de capacités des utilisateurs et des organisations que comme la promesse qu’une chaîne rendrait une personne indépendante des issuers, des verifiers ou du droit.
Conformité et liste pratique de vérification
Les systèmes d’identité gardent des obligations juridiques et opérationnelles. Selon la juridiction et l’usage, un opérateur peut avoir besoin d’une base légale, d’une limitation de finalité, de minimisation, de contrôles de conservation, de procédures d’accès et de rectification, de mesures de sécurité, de réponse aux incidents, de contrôles de transfert transfrontalier et d’un cadre de confiance auditable. Les documents European Digital Identity Wallet insistent sur le partage des seules informations convenues, et les recommandations du NIST sur le proofing montrent que validation, contrôles de révocation quand ils existent et assurance d’authentification sont des étapes distinctes. Ce sont des exigences de gouvernance autour d’un credential technique, pas des fonctions qu’un DID ou une blockchain supprime.
Pour une intégration réelle, posez sept questions. Quels DID method et registry sont utilisés, et comment les échecs de résolution sont-ils traités ? Quel issuer est reconnu pour cette affirmation et comment le subject a-t-il été vérifié ? Quels mécanisme de protection, cryptosuite, relation de clé et liaison de présentation sont exigés ? Comment contrôle-t-on la validité, le statut, la rotation, la compromission et la récupération ? La demande réclame-t-elle plus de données que la décision n’en exige, et la présentation résiste-t-elle au rejeu et à la corrélation ? Où sont conservés les credentials, les journaux et les enregistrements de statut, et pendant combien de temps ? Enfin, quel régulateur, contrat, liste de confiance ou politique interne détermine si le verifier peut se fier à l’affirmation ? L’expression verifiable credentials blockchain décrit des possibilités d’infrastructure, pas une garantie de vérité, de confidentialité ou de conformité.
Articles associés
Autres articles Bitbase sur ce sujet :
- Mixeurs crypto et privacy pools
- Billions Network : une plateforme d’identité respectueuse de la confidentialité
Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en août 2026 ; référez-vous aux informations officielles les plus récentes.
Sources
[1] W3C: Decentralized Identifiers v1.0 w3.org
[2] W3C: Verifiable Credentials Data Model v2.0 w3.org
[3] W3C: Verifiable Credential Data Integrity 1.0 w3.org
[4] NIST: Digital Identity Guidelines nist.gov
[5] European Commission: European Digital Identity europa.eu
