Aller au contenu
Financial Context Wiki

Identité décentralisée (DID)

Guide pratique des identifiants décentralisés et justificatifs vérifiables : portée des preuves, émission, présentation et risques persistants de confiance, de confidentialité et de récupération.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

L’identité décentralisée est une architecture dans laquelle un sujet utilise des identifiants et des justificatifs protégés par cryptographie entre plusieurs services, sans faire d’un compte de plateforme la source universelle d’identité. Ses composants courants sont les identifiants décentralisés (DID), les justificatifs vérifiables (VC), le logiciel du détenteur tel qu’un portefeuille et les règles indiquant quels émetteurs, éléments de preuve et niveaux d’assurance sont acceptés.

Un DID est un URI comme did:example:123. Sa méthode DID définit la création, la résolution, la mise à jour et la désactivation. La résolution peut produire un document DID contenant des méthodes de vérification, des relations comme authentication ou assertionMethod et des points de service facultatifs. Contrôler la clé correspondante prouve le contrôle du DID selon cette méthode ; cela ne prouve pas à soi seul un nom légal, un âge, l’unicité, un emploi ou la propriété d’un compte externe.

Un justificatif vérifiable porte les affirmations d’un émetteur sur un ou plusieurs sujets. Le détenteur le conserve et crée une présentation vérifiable pour un vérificateur. Une vérification cryptographique réussie établit l’intégrité et l’auteur des données protégées selon le mécanisme choisi. Le vérificateur doit encore décider s’il fait confiance à l’émetteur, si les affirmations satisfont sa politique, si le justificatif est actuel et si le présentateur peut l’utiliser.

« Décentralisée » ne veut donc pas dire sans confiance, anonyme, sur blockchain ou sans intermédiaire. Identifiants, justificatifs, registres, portefeuilles et politiques peuvent être séparés afin qu’un seul fournisseur de connexion n’observe ni ne contrôle chaque relation. La décentralisation réelle dépend des émetteurs, opérateurs de méthode DID, services de statut, fournisseurs de portefeuille, administrateurs de récupération, clés de gouvernance et politiques des vérificateurs.

Fonctionnement

  1. Définir l’affirmation et le cadre de confiance. Il faut préciser sujet, attributs demandés, émetteurs acceptés, processus de preuve, niveau d’assurance, conservation, juridiction et recours. Un format cryptographique ne décide pas si une université, une administration, un employeur ou une communauté fait autorité.
  2. Créer ou obtenir identifiants et clés. Émetteur et détenteur peuvent utiliser des DID, URL HTTPS ou autres identifiants pris en charge. Avec un DID, la méthode fixe le registre et le cycle de vie. Le contrôleur protège la clé privée ; le document résolu n’expose que le matériel et les points nécessaires.
  3. Vérifier et lier le sujet. L’émetteur contrôle les preuves selon sa politique puis lie les affirmations au sujet du justificatif. Le lien peut viser une clé contrôlée par le détenteur, un compte ou un autre identifiant. Il faut distinguer la preuve concernant une personne de celle que le présentateur contrôle une clé.
  4. Émettre le justificatif. L’émetteur crée affirmations, dates de validité, schéma ou type et référence de statut, puis sécurise le justificatif avec une preuve compatible. Dans Data Integrity, cryptosuite, verificationMethod, proofPurpose et proofValue indiquent comment vérifier la preuve.
  5. Stocker et sélectionner. Le détenteur conserve le justificatif dans un portefeuille local ou hébergé. Celui-ci doit expliquer la demande, ne divulguer que les données nécessaires si le format le permet et éviter de réutiliser silencieusement un identifiant stable dans des contextes sans rapport.
  6. Présenter avec fraîcheur et liaison au destinataire. Le vérificateur envoie identité, finalité, nonce ou défi et expiration. Le détenteur renvoie le justificatif ou une présentation dérivée liée à cette demande. Vérifier domaine et défi empêche la réutilisation face à un autre vérificateur ou dans une autre session.
  7. Vérifier cryptographie et politique. Le matériel de l’émetteur est résolu depuis une source authentifiée ; suite, finalité, défi, domaine, dates, schéma et statut sont validés ; puis les règles métier s’appliquent. verified: true alimente l’autorisation mais n’ordonne pas l’accès.
  8. Gérer le cycle de vie. Rotation des clés compromises, suspension ou révocation, mise à jour du statut, récupération et recours, conservation des preuves d’audit et plans de migration ou d’arrêt sont nécessaires. La vérification historique exige des règles sur anciennes clés, anciens documents et moment de présentation.

Les trois rôles sont émetteur, détenteur et vérificateur ; le sujet peut différer du détenteur. Un parent peut conserver un justificatif sur un enfant, un mandataire présenter celui d’une organisation. Sans liaison établie par le justificatif et le protocole, l’implémentation ne doit pas supposer que le présentateur est le sujet.

DID et VC sont indépendants. Une VC peut employer un identifiant d’émetteur non DID et un DID exister sans VC. Une méthode DID peut utiliser blockchain, base distribuée, domaine web ou échange pair à pair. Sécurité et gouvernance s’évaluent directement, sans être déduites du préfixe did:.

Exemple pratique

Un service doit confirmer qu’un client a au moins 18 ans sans recueillir sa date de naissance. Une autorité acceptée vérifie le client et émet un justificatif d’âge vers son portefeuille. Celui-ci peut contenir la date ou seulement l’affirmation ageOver18 ; les propriétés de divulgation et de réutilisation diffèrent.

À l’inscription, le service demande pour merchant.example une présentation attestant 18 ans, avec défi n-7f3a et fenêtre de 5 minutes. Le portefeuille montre la demande et, si le justificatif et la suite le permettent, dérive une présentation ne révélant que le prédicat utile. Le service vérifie méthode, preuve, défi, domaine, fenêtre et statut avant d’enregistrer le résultat minimal requis par l’audit.

Ce flux limite la conservation d’images ou de dates complètes, sans éliminer confiance ni risque. L’autorité peut inscrire la mauvaise personne ; portefeuille ou appareil peuvent être compromis ; identifiant stable ou requête de statut peuvent corréler les usages ; le service peut exiger trop de données ; une suspension erronée peut refuser l’accès. La divulgation sélective limite les données présentées, pas tous les métadonnées visibles par émetteurs, portefeuilles, réseaux et vérificateurs.

La rotation des clés montre une autre limite. Si l’émetteur remplace une clé compromise, les nouveaux justificatifs doivent utiliser la nouvelle méthode. La vérifiabilité d’un ancien dépend de l’historique DID, de l’heure de preuve, de la politique et du statut. Supprimer simplement l’ancienne clé du document actuel peut casser les contrôles historiques légitimes ou masquer la clé autorisée lors de la création.

Risques et contrôles

  • Affirmations fausses ou trop larges : Une signature valide conserve ce que dit l’émetteur, sans le rendre exact. Définir preuves, responsabilité, assurance, audits, expiration et correction.
  • Lien faible avec le détenteur : Un justificatif copié peut servir à autrui si la présentation ne prouve pas le contrôle de la clé prévue. Lier la preuve de possession au vérificateur, au défi, à la finalité et à la session si nécessaire.
  • Compromission des clés et du portefeuille : Logiciel malveillant, hameçonnage, prise de contrôle cloud ou sauvegarde faible exposent justificatifs et clés. Utiliser authentification résistante au hameçonnage, matériel si justifié, signalement et récupération limitée.
  • Centralisation de la récupération : Un administrateur unique peut devenir le vrai contrôleur. Documenter qui remplace les clés, quelles preuves sont requises, comment détecter l’abus et comment contester ou migrer.
  • Corrélation : Réutiliser DID, méthode, signature, endpoint ou chemin de statut relie les activités. Employer identifiants par paire, clés ou preuves séparées par domaine, statut confidentiel et tests de métadonnées.
  • Données personnelles publiques : Documents DID et historique peuvent être indexés et difficiles à effacer. Exclure noms, numéros, biométrie et affirmations personnelles des documents publics et registres immuables.
  • Confidentialité et disponibilité du statut : Contacter l’émetteur à chaque contrôle révèle l’usage ; une panne bloque les utilisateurs valides. Préférer un statut confidentiel et mis en cache, avec fraîcheur, mises à jour authentifiées et comportement d’échec défini.
  • Abus de révocation : Émetteur ou administrateur peut censurer par suspension ou modification du statut. Limiter l’autorité, journaliser, exposer motif et recours, permettre remplacement ou autre émetteur.
  • Risque de résolution et de méthode : Un résolveur peut renvoyer un document périmé ou malveillant, une méthode dépendre d’une infrastructure centrale. Authentifier le résultat et évaluer finalité, autorisation, disponibilité, gouvernance et version.
  • Décalage sémantique : Deux systèmes peuvent lire les mêmes champs et interpréter différemment affirmation, unité, juridiction ou assurance. Employer schémas et vocabulaires stables, valider contexte et type, versionner la politique.
  • Rejeu et confusion du vérificateur : Une présentation non liée au nonce, destinataire, domaine, action et expiration peut être réutilisée ou redirigée. Valider chaque liaison du protocole.
  • Divulgation excessive : Malgré la divulgation sélective, un vérificateur peut réclamer tout le justificatif. Imposer la minimisation dans politique et interface, consigner la finalité et ne pas rendre les champs facultatifs obligatoires par habitude.
  • Verrouillage de l’écosystème : Portefeuilles, preuves, registres ou récupération propriétaires réduisent la portabilité. Tester conformité, export, portefeuilles multiples, agilité cryptographique et migration.
  • Captation de gouvernance : Multisignature ou registre ne garantissent pas un contrôle large si un fournisseur choisit émetteurs, mises à jour, schémas et statuts. Cartographier l’autorité par composant et publier les contrôles de changement.

Idées reçues

  • « Un DID prouve qui est une personne. » Il identifie un sujet et peut exposer des méthodes ; les attributs exigent affirmations, preuves et décisions de confiance supplémentaires.
  • « Un justificatif valide rend l’affirmation vraie. » La vérification montre la preuve attendue et l’absence de modification, pas la qualité de l’enquête initiale.
  • « Le détenteur est toujours le sujet. » Les rôles peuvent différer ; une liaison explicite entre sujet et présentateur est nécessaire lorsque le cas l’exige.
  • « Tout doit être sur la blockchain. » Le stockage public immuable amplifie confidentialité, corrélation, effacement et gouvernance. Beaucoup gardent les justificatifs hors chaîne.
  • « La divulgation sélective garantit l’anonymat. » Attributs, identifiants, empreintes de preuve, requêtes, temps, IP et journaux peuvent encore corréler.
  • « Décentralisé signifie sans émetteur ni administrateur de confiance. » La confiance est distribuée et explicite, non supprimée. Émission, preuve, portefeuille, récupération, statut et acceptation restent gouvernés.
  • « Un DID égale un humain. » Une personne contrôle plusieurs DID ; un DID peut identifier organisation, appareil, données, rôle ou autre sujet. Unicité et humanité exigent d’autres mécanismes.
  • « Une signature de portefeuille suffit à authentifier. » Elle prouve le contrôle d’une clé sous conditions. Il faut encore résistance au hameçonnage, fraîcheur, destinataire, autorisation et récupération.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...