did:web expliqué
Chaque credential numérique est signé par quelqu'un, et un vérificateur doit pouvoir rechercher de qui il s'agit et quelles clés cette partie utilise aujourd'hui. did:web répond à cela avec l'infrastructure que presque toute organisation possède déjà : son propre nom de domaine. L'identifiant vous dit quel domaine interroger, la réponse est un simple fichier servi en HTTPS, et rien d'autre n'a besoin d'exister pour que cela fonctionne.
Ce qu'est réellement did:web
Une DID est un identifiant permanent que chacun peut consulter pour trouver les clés publiques de celui qui la détient. Une méthode DID est la règle qui décrit cette consultation, et il en existe des dizaines. Certaines inscrivent l'enregistrement sur une blockchain, d'autres sur un réseau conçu à cet effet, et chacune oblige un vérificateur à apprendre le fonctionnement de ce système particulier.
did:web prend le chemin inverse. La consultation est une requête HTTPS vers le domaine nommé dans l'identifiant, et l'enregistrement est un fichier JSON que le propriétaire du domaine publie et modifie comme n'importe quelle autre page de son site. Il n'y a pas de réseau à rejoindre, pas de registre où écrire et pas de frais à payer.
C'est pourquoi il apparaît si tôt dans presque tous les projets. Une équipe capable de déposer un fichier sur son serveur web peut délivrer et vérifier des credentials l'après-midi même, et l'identifiant obtenu est une vraie DID que tout wallet ou vérificateur conforme acceptera, pas une solution provisoire à remplacer plus tard.
Comment l'identifiant devient une URL
La correspondance est mécanique, et c'est tout l'intérêt. Un domaine nu mène à un fichier dans le répertoire well-known que les sites utilisent déjà pour leurs métadonnées lisibles par machine. Ajoutez après le domaine des segments séparés par des deux-points et ils deviennent des segments de chemin, de sorte qu'une organisation peut publier un identifiant distinct par service, par environnement ou par système de délivrance sans rien enregistrer de nouveau.
Deux détails échappent souvent. Un numéro de port impose d'encoder son deux-points en pourcentage, parce qu'un deux-points simple sépare déjà les parties de l'identifiant. Et le fichier doit être servi en HTTPS avec un certificat qui se valide, puisque le transport est la seule chose qui se dresse entre un vérificateur et une réponse falsifiée.
L'identifiant que quelqu'un vous donne
did:web:example.com:issuer:euL'URL HTTPS vers laquelle il pointe, sans service d'annuaire intermédiaire
https://example.com/issuer/eu/did.jsonLe DID document renvoyé, contenant les clés et les points de terminaison
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Pourquoi les organisations le choisissent
La première raison est la reconnaissance. Un vérificateur qui voit un identifiant pointant vers le domaine d'une entreprise peut vérifier, de la manière la plus simple qui soit, que le nom figurant sur le credential correspond au nom du site. Il n'y a ni recherche au registre ni chaîne de certificats à expliquer à quiconque avant que cela porte.
La deuxième est que son exploitation ne coûte rien. Le document vit derrière le même hébergement, la même supervision et le même processus de changement que le reste du site. Il n'y a pas de système distinct à financer, à maintenir disponible ou à expliquer à un auditeur, et faire tourner une clé relève d'un déploiement plutôt que d'une transaction.
La troisième est la portabilité. Parce que toutes les bibliothèques de wallet et de vérification la prennent en charge, did:web est la méthode qui a le plus de chances de fonctionner face à un partenaire avec lequel vous n'avez jamais intégré, ce qui en fait le choix naturel pour les pilotes, les environnements de test et les événements d'interopérabilité où se rencontrent les implémentations européennes de wallet.
Là où did:web s'arrête
Tout ce que la méthode vous apporte repose sur le domaine. Qui contrôle l'enregistrement, les serveurs de noms et le certificat contrôle l'identifiant : un renouvellement oublié, un compte DNS détourné ou un certificat délivré à tort suffit à parler en votre nom. Il n'y a pas de seconde signature en dessous sur laquelle se rabattre.
Il n'a pas non plus de mémoire. Un vérificateur voit le document tel qu'il est à l'instant présent et n'a aucun moyen de savoir ce qu'il disait la semaine passée, donc une clé remplacée est indiscernable d'une clé simplement renouvelée. did:webvh existe précisément pour cela : le même hébergement web, plus un journal signé de chaque modification où l'on ne peut qu'ajouter, afin qu'un vérificateur puisse suivre l'historique de la première entrée jusqu'à l'état actuel.
Et ce n'est pas un contrôle d'identité. Publier un document sous un domaine prouve le contrôle de ce domaine et rien de plus. Lorsqu'un vérificateur doit savoir qu'une personne morale est bien celle qu'elle prétend être, cette assurance vient d'une Trusted List, d'un certificat qualifié ou d'un Trust Framework conçu pour cela, la méthode DID ne portant que les clés en dessous.
Ce que cela signifie pour vous
Émetteur
Traitez le document comme une infrastructure de production dès le premier jour. Placez-le sous contrôle des changements, surveillez que l'URL répond et que le certificat est valable, et gardez une clé retirée listée pour la vérification tant que quelque chose signé avec elle reste en circulation.
Partie utilisatrice
Récupérer le document n'est pas la même chose que lui faire confiance. Décidez séparément quels domaines vous acceptez, refusez tout ce dont le certificat ne se valide pas, et mettez en cache avec soin : une copie périmée maintient en vie une clé révoquée, une copie absente fait tomber votre service en même temps que celui d'en face.
Titulaire du portefeuille
Le domaine figurant dans l'identifiant d'un émetteur mérite un coup d'oeil. C'est la seule partie d'un credential que vous pouvez lire sans outil, et un nom qui ne correspond pas à l'organisation attendue est une raison de s'arrêter plutôt que de poursuivre.
Termes associés
Questions fréquentes
Ai-je besoin d'un logiciel particulier pour résoudre un identifiant did:web ?
Non. L'identifiant est une recette pour construire une URL, et récupérer cette URL en HTTPS renvoie le document. N'importe quel client HTTP en est capable, et c'est pourquoi did:web est en général la première méthode qu'une équipe met en service. Une bibliothèque de résolution générique reste utile en production, car elle applique les règles d'encodage et les contrôles sur le document de façon uniforme au lieu de les laisser à chaque appelant.
did:web est-il moins fiable parce qu'il n'y a pas de blockchain ?
Il est fiable autrement. Une méthode fondée sur un registre distribué répartit l'enregistrement entre de nombreuses parties, de sorte qu'aucune ne peut le réécrire discrètement. did:web place cette responsabilité sur le propriétaire du domaine et sur les autorités de certification derrière son TLS. Pour une organisation dont le nom et le site sont déjà ce que les clients reconnaissent, c'est souvent l'endroit le plus honnête où placer cette confiance, tant que chacun comprend que le domaine est le point faible.
Qu'advient-il des credentials déjà délivrés lorsque les clés changent ?
Un vérificateur récupère le document tel qu'il est à cet instant, donc un credential signé avec une clé retirée depuis ne se vérifie plus. Conservez une clé retirée dans le document, marquée de façon à pouvoir vérifier mais plus signer, au moins aussi longtemps que les credentials qu'elle a signés restent valables. Si un vérificateur doit pouvoir prouver quelle clé était en vigueur à une date donnée, c'est là que did:webvh justifie sa complexité supplémentaire.
Sources
Cette page est informative et ne constitue pas un conseil juridique. Pour des indications faisant autorité, consultez directement les spécifications du W3C.