Decentralized Identifier (DID)

Ein Decentralized Identifier (DID) ist ein Bezeichner, mit dem der Kontrolleur (controller) nachweisen kann, dass er den Bezeichner kontrolliert, und zwar ohne zentrale Registry, ohne Identitätsanbieter und ohne Zertifizierungsstelle. Beschrieben ist er als Typ von Identifier für verifizierbare, dezentrale digitale Identität. Das W3C hat DIDs in Version 1.0 als Recommendation veröffentlicht.

So funktioniert es

Jeder DID gehört zu einer DID-Methode. Die Methode definiert, wie ein Bezeichner erzeugt, gelesen, aktualisiert und deaktiviert wird. Viele Methoden stützen sich dafür auf eine schwergewichtige Registry, etwa ein Distributed Ledger. Eine Auflösung (resolution) liefert aus dem DID das DID-Dokument mit dem Verifikationsmaterial, gegen das Signaturen geprüft werden. Bei did:key ist der öffentliche Schlüssel selbst der Bezeichner, bei did:webvh bindet sich der Bezeichner an eine Domain und führt eine verifizierbare Schlüsselhistorie. Im VC-Datenmodell sind DIDs optional, Credentials und DIDs hängen nicht voneinander ab.

Zwei Eigenschaften unterscheiden die Methoden praktisch: ob eine Registry gebraucht wird und ob sich der Bezeichner rotieren lässt. did:key braucht keine Registry und kann nicht rotieren, did:webvh führt dafür eine Historie. Wer einen DID prüft, löst ihn also je nach Methode lokal oder über das Netz auf.

Im Vergleich

Der Decentralized Trust Graph kennt in seiner aktuellen Fassung ausschließlich DIDs als Identifier der Credentials. Spätere Versionen könnten andere Typen wie X.509 oder KERI AIDs zulassen. Die Trust-Tasks-Spezifikation arbeitet bereits mit dem allgemeineren Begriff VID: ein Identifier, dessen Kontrolleur unter einem Trust Framework verifizierbar ist. In der Verifiable Trust Infrastructure (VTI) muss die dauerhafte Identität von Agent, Community und Host-Dienst ein did:webvh sein, die Bootstrap-Identität eines Clients ein did:key.

Das Real Life Trust Protocol spezifiziert eine einzige Methode, did:key über Ed25519. Die Foundations-Seite hält fest, dass did:webvh und did:peer nicht spezifiziert sind. Konsumenten behandeln den Anker als undurchsichtige DID, die Schemas legen aber das did:key-Muster fest, sodass ein Methodenwechsel eine koordinierte Änderung wäre. Eine Schlüsselhistorie nach Art von KERI ist als offene Arbeit benannt, ihr Format wurde bewusst noch nicht gewählt.

Einordnung

Diese Erläuterung gehört zu den Fachnotizen über das Real Life Trust Protocol und gibt den Stand der Spezifikationen vom Oktober 2026 wieder.

Quelle

https://www.w3.org/TR/did-1.0/