Decentralized Identifiers (DIDs) – Ein Einblick

19.05.2023

Decentralized Identifiers ist ein neuer Identifizierungstyp, der eine verifizierbare, dezentralisierte Identität ermöglicht. Dabei ist keine zentrale Registrierung erforderlich. DIDs sind so konstruiert, dass sie sich von zentralen Registrierungen, Identity Providers (IdPs) und Zertifizierungsstellen lösen können.

Was sind DIDs?

Das World Wide Web Consortium (W3C) hat im Juli 2022 Decentralized Identifiers (DID) als offiziellen Web-Standard eingeführt. Obwohl DID sich noch in einer frühen Phase befindet, verspricht er Web-Benutzern mehr Kontrolle über ihre digitalen Identitäten.

Individuen und Organisationen sind auf Identifiers (IDs) wie Telefonnummern, E-Mail-Adressen und Benutzernamen angewiesen. Die meisten IDs werden jedoch von externen Verwaltungen ausgestellt und kontrolliert. Diese Verwaltungen entscheiden, auf wen oder was sich diese IDs beziehen und wann sie widerrufen werden können. Bei den meisten E-Mail-Adressen haben die Individuen, die sie erstellt haben, keine direkte Kontrolle. Mit W3C DIDs können Individuen und Organisationen nun die Kontrolle über ihre Identitäten übernehmen.

DID wird als neuer Standard sowohl Individuen als auch Organisationen mehr Kontrolle über ihre Online-Informationen und -Beziehungen ermöglichen. Gleichzeitig wird eine erhöhte Sicherheit und Privatsphäre gewährleistet.

DIDs können sich auf Personen, Organisationen, Gegenstände, Datenmodelle oder abstrakte Entitäten beziehen, die durch einen sogenannten DID-Controller bestimmt werden.

Eine DID wird durch einen einfachen String repräsentiert, der aus drei Teilen besteht: einem URI-Schema zur DID-Kennung, der Kennung zur DID-Methode und einer spezifizierten ID durch die DID-Methode. In Abbildung 1 ist ein einfaches Beispiel eines Decentralized Identifier (DID) dargestellt.

image-2023-5-17_17-5-26.png
Abbildung 1: Aufbau eines DIDs (https://www.w3.org/TR/did-core/

Eine DID-URL erweitert die Syntax eines grundlegenden DIDs, um andere Standard-URI-Komponenten wie Pfad, Abfrage und Fragment einzubauen. Dadurch kann eine bestimmte Ressource lokalisiert werden, zum Beispiel ein kryptografischer Public Key innerhalb eines DID-Dokuments oder eine externe Ressource, die mit dem DID-Dokument verbunden ist. Eine DID-URL bezieht sich auf ein DID-Subjekt und wird in ein DID-Dokument aufgelöst.

Das DID-Subjekt ist die Entität, die durch die DID identifiziert wird. Das DID-Subjekt kann auch der DID-Controller sein. Alles kann das Subjekt eines DIDs sein: eine Person, eine Gruppe, eine Organisation, ein Gegenstand oder ein Konzept.

Der DID-Controller ist die Entität (Person, Organisation oder autonome Software), die gemäß der DID-Methode befugt ist, Änderungen an einem DID-Dokument vorzunehmen. Dies wird in der Regel durch die Kontrolle einer Menge von kryptografischen Schlüsseln sichergestellt, die von einer vom Controller gesteuerten Software verwendet werden.

Wie der Name schon sagt, kann nur ein DID-Controller diejenigen Aktionen ausführen, die einen DID kontrollieren. Das in Abbildung 1 dargestellte Beispiel-DID wird in ein DID-Dokument aufgelöst. Dieses Dokument enthält Informationen, die mit dem DID verbunden sind, wie z.B. Wege zur kryptografischen Authentifizierung eines DID-Controllers. Ein einfaches DID-Dokument ist in Abbildung 2 zu sehen.

image-2023-5-17_17-6-10.png
Abbildung 2: vereinfachtes DID-Dokument (https://www.w3.org/TR/did-core/)

DID-Dokumente enthalten Informationen, die mit einem DID in Verbindung stehen. Diese Dokumente enthalten in der Regel Verifizierungsmethoden wie kryptografische Public Keys für digitale Signaturen oder Dienste, die mit dem DID-Subjekt interagieren. Ein DID-Dokument kann in einen Byte-Stream umgewandelt werden. Eine Verifizierungsmethode besteht aus einer Reihe von Parametern, die verwendet werden können, um unabhängig voneinander einen Nachweis zu verifizieren.

Um ein DID-Dokument auflösen zu können, wird ein DID normalerweise in einem zugrundeliegenden System oder Netzwerk erfasst. Unabhängig von der verwendeten Technologie wird jedes solche System, das DIDs aufnehmen und die für die Erzeugung eines DID-Dokuments erforderlichen Daten zurückgeben kann, als verifizierbares Datenregister (Verifiable Data Registry) bezeichnet. Beispiele dafür sind Distributed Ledgers, dezentralisierte Dateisysteme, Datenbanken jeglicher Art, Peer-to-Peer-Netzwerke und andere Formen der vertrauenswürdigen Datenspeicherung.

Die DID-Methode ist, wie zuvor erwähnt, Teil des DIDs gemäß Abbildung 1. Eine DID-Methode ist der Mechanismus, durch den ein bestimmter DID-Typ und das zugehörige DID-Dokument ähnlich dem CRUD-Prinzip erstellt, aufgelöst (resolved), aktualisiert und deaktiviert werden.

Für die Auflösung eines DID-Dokuments gibt es einen sogenannten DID-Resolver. Der DID-Resolver ist eine Systemkomponente, die ein DID als Eingabe erhält und ein gültiges DID-Dokument als Ausgabe liefert. Dieser Prozess wird als DID-Resolution bezeichnet. Die spezifischen Schritte der DID-Resolution für einen bestimmten DID-Typ werden in der entsprechenden DID-Methodenspezifikation definiert.

Ein DID-URL-Dereferenzierer ist eine Systemkomponente, die eine DID-URL als Eingabe erhält und eine Ressource als Ausgabe liefert. Dieser Prozess wird auch als DID-URL-Dereferenzierung bezeichnet.

image-2023-5-17_17-7-11.png
Abbildung 3: DID-Architektur (https://www.w3.org/TR/did-core/)

DIDs ermöglichen es Benutzern, über ihre eigene Identität zu verfügen, sie auf verschiedene Plattformen zu übertragen, in beliebigen Anwendungen zu verwenden und zu entscheiden, welche Daten sie mit Service Providern teilen möchten. Individuen und Organisationen können ihre eigenen IDs mithilfe von vertrauenswürdigen Systemen generieren.

Der häufigste Anwendungsfall für DIDs liegt im Bereich der sogenannten Verifiable Credentials (VCs). VCs sind ähnlich wie offizielle Dokumente zur Benutzeridentität, z.B. Geburtsurkunden, Führerscheine, Sozialversicherungskarten und andere Informationen, die eine Person betreffen.

Ein Verifiable Credential kann dieselben Informationen wie ein physisches Credential repräsentieren, jedoch sind VCs durch Technologien wie digitale Signaturen manipulationssicherer und vertrauenswürdiger als ihre physischen Versionen. Die VC-Spezifikation basiert auf den verschiedenen Rollen und dem Informationsfluss.

DIDs sind im Allgemeinen als Teil größerer Systeme wie dem VC-Ökosystem zu verstehen. Nahezu jeder Typ von ID-System kann DID-Unterstützung integrieren, was eine Brücke zwischen zentralisierten, föderierten und dezentralisierten IDs schafft. Es ermöglicht auch Implementierern, spezifische Arten von DIDs zu konstruieren, um sie mit ihrer vertrauten Rechnerinfrastruktur kompatibel zu machen, z.B. Peer-to-Peer-Netzwerke, verteilte Datenbanken oder dezentralisierte Dateisysteme.

Abbildung 4 zeigt die von DIDs unterstützten Aktionen Create, Read, Update, Delete (CRUD) und Use. Die in Nummer drei dargestellte Aktion ist die Authentifizierung, die zur Kategorie Use gehört.

image-2023-5-17_17-7-55.png
Abbildung 4: Übersicht der DID-Use-Cases (https://w3c-ccg.github.io/did-use-cases/

Relying Parties möchten gegebenenfalls einen Nachweis darüber haben, dass eine Person, die eine DID vorweist, tatsächlich die Kontrolle darüber hat oder als Controller für einen bestimmten Service-Endpunkt spezifiziert ist. Dieser Authentifizierungsprozess nutzt das kryptografische Material im DID-Dokument, um mithilfe einer Challenge-Response zu überprüfen, ob der selbsternannte Controller tatsächlich die Kontrolle über die DID hat.

Einige DID-Dokumente und -Methoden ermöglichen separate Nachweise für verschiedene Service-Endpunkte, die unabhängig von Update- und Delete-Operationen sind. Diese Trennung ermöglicht häufig verwendete transaktionale Nachweise, während Kontrollnachweise weniger häufig verwendet werden.

DIDs zielen darauf ab, die Authentifizierung von zentralisierten oder föderierten Ansätzen wie OAuth hin zu einer dezentralisierten Infrastruktur zu verschieben.

Ein typisches Beispiel für die Authentifizierung bei DIDs ist der Nachweis der Kontrolle über den kryptografischen Private Key, der mit einem im DID-Dokument veröffentlichten Public Key verbunden ist.

Der Ablauf der Authentifizierung als Teil der DID-Verwendung wird in Abbildung 5 dargestellt.

image-2023-5-17_17-11-0.png
Abbildung 5: Ablauf einer DID-Authentifizierung (eigene Darstellung)

In der Abbildung wird das Challenge-Response-Verfahren mit Signierung durch den DID-Controller dargestellt. Eine Verifizierungsbeziehung zeigt die Verbindung zwischen dem DID-Subjekt und einer zuvor erwähnten Verifizierungsmethode auf, z.B. ein kryptografischer Public Key. Die Authentifizierung ist eine spezifische Verifizierungsmethode, die angibt, wie das DID-Subjekt authentifiziert werden soll. Die Authentifizierung wird bei DIDs für Zwecke wie das Einloggen auf einer Webseite oder Interaktionen mit einem Challenge-Response-Protokoll verwendet. Es ist optional, die Authentifizierung als Eigenschaft im DID-Dokument anzugeben, das Verifizierungsmethoden definiert.

Bei der DID-Authentifizierung folgt man dem Challenge-Response-Prinzip. Eine Relying Party stellt dem Identity Owner eine Aufgabe (Challenge), die den Identity Owner auffordert, eine Antwort zu liefern, die seine Kontrolle über eine DID nachweist.

Quellen:

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

https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.pdf

https://w3c-ccg.github.io/did-use-cases/

https://www.w3.org/TR/vc-data-model/

https://portswigger.net/daily-swig/decentralized-identifiers-everything-you-need-to-know-about-the-next-gen-web-id-tech

https://www.w3.org/2022/07/pressrelease-did-rec.html.en

 

 

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*Pflichtfelder

*