did:web

Un identifiant did:web tel que did:web:example.com correspond directement à une URL comme https://example.com/.well-known/did.json, de sorte que n'importe quel client HTTPS standard peut récupérer le DID document sans faire tourner de logiciel de résolution spécialisé. Des segments supplémentaires séparés par des deux-points deviennent des segments de chemin : did:web:example.com:issuer:eu mène alors à https://example.com/issuer/eu/did.json.

C'est le document situé à cette URL qui donne son sens à l'identifiant. Il énumère les clés publiques autorisées à signer pour le sujet, indique lesquelles peuvent authentifier ou émettre des assertions, et nomme les points de terminaison de service que le sujet publie. Faire tourner une clé revient à modifier ce seul fichier.

La confiance dans la DID dépend entièrement du contrôle du domaine et de son certificat TLS : un enregistrement expiré, un serveur de noms détourné ou un certificat délivré à tort suffit à parler au nom du propriétaire. Il n'y a pas de seconde signature en dessous sur laquelle se rabattre.

Le DID document ne reflète par ailleurs que son état actuel : rien dans la méthode elle-même n'enregistre ni ne prouve à quoi il ressemblait avant la dernière modification, et c'est la lacune que did:webvh comble en ajoutant, sur le même hébergement web, un historique signé où l'on ne peut qu'ajouter.