Blog · 28. Juli 2026

W3C Dezentrale Identifikatoren (DIDs) – Eine Spezifikation (DE)

Eine technische Erklärung der W3C DID Core Spezifikation: Syntax von Identifikatoren und DID-URLs, Subjekte, Controller, DID-Dokumente, Methoden, Auflösung, Verifizierungsbeziehungen, Dienste, Datenschutz und Verifiable.

Von Didit28. Juli 2026Aktualisiert 28. Juli 2026

Die W3C-Spezifikation für Dezentrale Identifikatoren (DIDs) definiert eine URI-Syntax, ein gemeinsames Datenmodell, DID-Dokumente, Kerneigenschaften, Repräsentationen, Methodenanforderungen und abstrakte Schnittstellen für die Auflösung und DID-URL-Dereferenzierung. DID Core 1.0 wurde am 19. Juli 2022 eine W3C-Empfehlung. DID Core 1.1 wurde am 5. März 2026 als Candidate Recommendation Snapshot veröffentlicht; es handelt sich um neuere Arbeiten in einem anderen Standardisierungsstadium.

DID Core erfordert keine Blockchain, beweist nicht die rechtliche Identität einer Person, speichert keine Anmeldeinformationen in jedem DID-Dokument oder macht jeden aufgelösten Endpunkt vertrauenswürdig. Es standardisiert die Architektur von Identifikatoren und Dokumenten. Eine separate DID-Methode definiert, wie eine bestimmte DID auf ihrer gewählten Infrastruktur erstellt, gelesen, aktualisiert und deaktiviert wird.

Wichtigste Erkenntnisse

Eine DID ist eine URI, keine Anmeldeinformation. Ihre generische Form ist did:<method-name>:<method-specific-id>.
Subjekt und Controller sind unterschiedliche Rollen. Das Subjekt ist das, was die DID identifiziert; der Controller ist von der Methode autorisiert, das DID-Dokument zu ändern.
Schlüssel benötigen explizite Zwecke. Eine Verifizierungsmethode wird nur durch die entsprechende Verifizierungsbeziehung für Authentifizierung, Bestätigung, Schlüsselvereinbarung, Fähigkeitsaufruf oder Delegation nutzbar.
Die Methode liefert die Betriebsregeln. DID Core ist technologieunabhängig; die Methode definiert die Interaktion mit dem Register, die Autorisierung, Aktualisierung, Deaktivierung und die methodenspezifische Auflösung.
Die Auflösung schafft allein kein Vertrauen. Implementierer müssen Methodenergebnisse authentifizieren, den Nachweiszweck durchsetzen, Schlüssel und Historie verwalten, den Datenschutz schützen und Anwendungsrichtlinien anwenden.

Was ist ein dezentraler Identifikator?

Ein dezentraler Identifikator ist ein Identifikator, der so konzipiert ist, dass die Kontrolle ohne einen zentralen Identitätsanbieter oder eine Zertifizierungsstelle hergestellt werden kann, die jeden Identifikator ausstellt und verwaltet. Das Wort „dezentral“ beschreibt die Fähigkeit der Architektur, die Identifikatorsteuerung von einem einzigen zentralen Aussteller zu trennen; es besagt nicht, dass jede Implementierung anonym, öffentlich, unveränderlich oder auf einem verteilten Ledger gespeichert ist.

Eine DID kann identifizieren:

eine Person;
eine Organisation oder Gruppe;
ein Gerät oder physisches Objekt;
eine digitale Ressource;
ein Datenmodell;
ein abstraktes Konzept.

Die identifizierte Entität ist das DID-Subjekt. Der String allein gibt den Subjekttyp nicht preis.

DID-Syntax

Die generische Syntax lautet:

did:<method-name>:<method-specific-id>

Zum Beispiel:

did:example:123456789abcdefghi

did ist das URI-Schema. example ist der DID-Methodenname. Der restliche String ist der methodenspezifische Identifikator. Die Methodenspezifikation definiert, was dieser Wert bedeutet und wie Software ihn verarbeitet.

Eine gültig aussehende DID ist nicht unbedingt nutzbar. Die Methode muss existieren und der Resolver muss sie unterstützen.

DID-URLs: Pfade, Abfragen und Fragmente

Eine DID-URL beginnt mit einer DID und kann einen Pfad, eine Abfrage oder ein Fragment hinzufügen:

did:example:123456789abcdefghi/path?service=messages#key-1

Diese Komponenten können identifizieren oder helfen, auszuwählen:

eine Verifizierungsmethode innerhalb des DID-Dokuments;
einen Diensteintrag;
ein weiteres DID-Dokumentfragment;
eine Ressource, die über einen Dienst erreicht wird;
eine Version oder eine methodendefinierte Option.

Das Fragment #key-1 identifiziert üblicherweise eine Verifizierungsmethode. Es bedeutet nicht, dass der private Schlüssel im Dokument enthalten ist. DID-Dokumente veröffentlichen öffentliches Verifizierungsmaterial oder Referenzen; geheimes Material muss anderweitig geschützt bleiben.

Die DID-Architektur

Die Hauptkonzepte sind miteinander verbunden, aber nicht austauschbar:

nody>

Konzept	Rolle
DID	Global eindeutiger Identifikator, der der DID-Syntax entspricht
DID-Subjekt	Person, Organisation, Sache, Ressource oder Konzept, das identifiziert wird
DID-Controller	Entität, die unter der DID-Methode autorisiert ist, das DID-Dokument zu ändern
DID-Dokument	Mit dem Subjekt verbundene Daten, einschließlich erlaubter Verifizierungsmethoden und Dienste
DID-Methode	Separate Spezifikation für methodenspezifische Syntax und Operationen
Überprüfbares Datenregister	Infrastruktur, die eine Methode verwendet, um den DID-Status zu erstellen, zu lesen, zu aktualisieren oder zu deaktivieren
DID-Resolver	Software oder Hardware, die die DID-Auflösung für unterstützte Methoden durchführt
DID-URL-Dereferencer	Software oder Hardware, die eine durch eine DID-URL identifizierte Ressource abruft

Subjekt versus Controller

Subjekt und Controller können dieselbe Entität sein, müssen es aber nicht. Ein Elternteil könnte eine DID für ein Kind kontrollieren, eine Organisation könnte eine DID für ein Gerät kontrollieren, oder mehrere Treuhänder könnten eine Wiederherstellungsvereinbarung kontrollieren.

Der oberste controller identifiziert einen oder mehrere DID-Controller. Der erforderliche controller einer Verifizierungsmethode identifiziert, wer diese Methode kontrolliert; es ist nicht automatisch der oberste DID-Controller. Eine Verwechslung kann unbeabsichtigte Autorität gewähren.

Was ist ein DID-Dokument?

Ein DID-Dokument sind die Daten, die einem DID-Subjekt unter dem DID Core-Datenmodell zugeordnet sind. Seine Stamm-id ist die DID. Optionale Kerneigenschaften können Controller, alternative Identifikatoren, Verifizierungsmethoden, Verifizierungsbeziehungen und Dienste beschreiben.

Dieses vereinfachte Beispiel verwendet öffentliches Material aus dem Beispielbereich der Spezifikation:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ"
      }
    }
  ],
  "authentication": [
    "did:example:123#key-1"
  ],
  "assertionMethod": [
    "did:example:123#key-1"
  ]
}

did:example ist für Beispiele reserviert; Produktionssysteme müssen eine tatsächliche Methode und deren aktuelle Anforderungen an die Verifizierungsmethodensuite verwenden. Das obige JSON ist absichtlich gültiges JSON. Viele Beispiele, die in technischen Spezifikationen abgedruckt sind, enthalten Kommentare oder Auslassungspunkte zur besseren Lesbarkeit und sollten nicht direkt in einen Parser kopiert werden.

Kerneigenschaften

id: die DID für das Subjekt; im Dokumentenstamm erforderlich.
controller: eine oder mehrere DIDs, die autorisiert sind, Änderungen unter der Methode vorzunehmen.
alsoKnownAs: andere URIs, die als Identifikatoren desselben Subjekts beansprucht werden.
verificationMethod: öffentliche Verifizierungsmechanismen, die durch explizite Beziehungen referenziert werden können.
authentication: Methoden, die zur Authentifizierung als Subjekt autorisiert sind.
assertionMethod: Methoden, die autorisiert sind, Behauptungen auszudrücken, wie z.B. die Ausstellung von Anmeldeinformationen.
keyAgreement: Methoden, die für die Ableitung von gemeinsamem geheimen Material vorgesehen sind.
capabilityInvocation: Methoden, die zum Aufrufen von Fähigkeiten autorisiert sind.
capabilityDelegation: Methoden, die zur Delegation von Fähigkeiten autorisiert sind.
service: Endpunkte oder Interaktionsmechanismen, die mit dem Subjekt verbunden sind.

alsoKnownAs ist eine Behauptung, kein kryptografischer Beweis, dass zwei Identifikatoren äquivalent sind. Anwendungen sollten die von ihrem Vertrauensmodell geforderte Beziehung unabhängig überprüfen.

Datenmodell und Repräsentationen

DID Core definiert ein abstraktes Datenmodell und Regeln für die Erzeugung und den Verbrauch von Repräsentationen. Das Datenmodell ist nicht identisch mit einer JSON-Serialisierung.

Die Anforderungen an die Repräsentation sind versionsspezifisch:

Die 2022 DID Core 1.0 Empfehlung definiert application/did+json und application/did+ld+json. Ihre JSON-LD-Repräsentation beginnt mit dem Basiskontext https://www.w3.org/ns/did/v1.
Die DID Core 1.1 Candidate Recommendation konsolidiert den Core-Medientyp zu application/did. Ihre JSON-LD-Repräsentation beginnt mit https://www.w3.org/ns/did/v1.1.

Mischen Sie nicht den Medientyp oder den Basiskontext einer Version mit Konformitätsansprüchen zur anderen. Legen Sie die Spezifikationsversion fest, die Produzenten und Konsumenten implementieren.

Implementierer sollten die Repräsentation explizit aushandeln und validieren. Das Signieren beliebiger serialisierter JSON-Bytes ohne eine definierte Kanonisierung und einen Sicherungsmechanismus ist nicht gleichbedeutend mit der korrekten Verarbeitung des DID-Datenmodells.

Verifizierungsmethoden und Verifizierungsbeziehungen

Eine Verifizierungsmethode beschreibt, wie ein Nachweis überprüft werden kann. Sie erfordert:

eine id, ausgedrückt als DID-URL;
einen type;
einen controller;
Verifizierungsmaterial, das diesem Typ entspricht.

Öffentliches Material kann durch eine definierte Eigenschaft wie publicKeyJwk oder eine andere Form, die von der Verifizierungsmethodensuite erlaubt ist, dargestellt werden. Ein JWK in einem DID-Dokument darf kein Material für private Schlüssel enthalten. Dasselbe Verifizierungsmaterial darf nicht in mehreren Materialeigenschaften innerhalb einer Methode dupliziert werden.

Die Definition einer Verifizierungsmethode autorisiert sie nicht für jeden Zweck. Die Autorisierung ergibt sich aus den fünf expliziten Verifizierungsbeziehungen.

Beziehung	Beabsichtigter Nachweiszweck
`authentication`	Authentifizierung als DID-Subjekt durch Challenge-Response oder einen anderen akzeptierten Mechanismus
`assertionMethod`	Ausdruck von Behauptungen, einschließlich der Signierung einer Verifiable Credential, wenn der gewählte Sicherungsmechanismus dies verwendet
`keyAgreement`	Aufbau gemeinsamen kryptografischen Materials, oft zur Verschlüsselung
`capabilityInvocation`	Aufruf einer Objektfähigkeit
`capabilityDelegation`	Delegation einer Objektfähigkeit

Ein Verifizierer muss die für den Nachweis erforderliche Beziehung überprüfen. Ein Schlüssel, der nur unter authentication aufgeführt ist, ist nicht automatisch für Anmeldeinformationen oder Schlüsselvereinbarungen autorisiert.

Beziehungen können eine vollständige Verifizierungsmethode einbetten oder eine solche über eine DID-URL referenzieren. Referenzen verbessern die Wiederverwendung, erfordern aber eine korrekte Dereferenzierung und einen exakten Identifikatorvergleich.

Dienste und Dienstendpunkte

Die optionale service-Eigenschaft kann Wege zur Kommunikation mit oder Interaktion mit dem DID-Subjekt bewerben. Jeder Diensteintrag hat:

eine eindeutige id;
einen type;
einen serviceEndpoint.

Der Endpunkt kann eine URI oder eine andere zulässige Struktur sein. Dienstdefinitionen sind erweiterbar, daher müssen Anwendungen den gewählten Typ verstehen.

Die Veröffentlichung eines Endpunkts beweist nicht, dass sein Server, Betreiber, Transport, Inhalt oder Ziel vertrauenswürdig ist.

Die Anwendung muss den aufgelösten DID-Status über die Methode authentifizieren, den Diensttyp validieren, URL- und Netzwerksicherheitskontrollen anwenden und ein Anwendungsprotokoll mit eigenen Sicherheitseigenschaften verwenden.

Öffentliche Dienstendpunkte können auch eine Korrelation erzeugen. Die Wiederverwendung eines Endpunkts über paarweise DIDs hinweg kann den Datenschutzvorteil separater Identifikatoren zunichtemachen.

Was eine DID-Methode definiert

DID Core liefert die gemeinsame Architektur. Eine konforme DID-Methode definiert die methodenspezifischen Regeln, die für ihre Implementierung notwendig sind, einschließlich:

Methodenname und methodenspezifische Identifikatorsyntax;
wie eine DID und ein anfängliches DID-Dokument erstellt werden;
wie der aktuelle Status gelesen wird;
wie autorisierte Updates eingereicht und überprüft werden;
wie eine DID deaktiviert wird;
wie die Auflösung mit dem Register kommuniziert;
wie die Authentizität und Integrität der Ergebnisse hergestellt wird;
wie Schlüsselrotation, Wiederherstellung, Versionierung und Historie funktionieren;
methodenspezifische Sicherheits- und Datenschutzaspekte.

Das überprüfbare Datenregister könnte ein verteiltes Ledger, ein dezentrales Dateisystem, ein Peer-to-Peer-Netzwerk, eine Datenbank oder ein anderes System sein. Die Architektur sollte nach Governance, Verfügbarkeit, Autorisierung, Datenschutz, Kosten, Historie und Angriffsresistenz bewertet werden, anstatt nur nach dem Wort „dezentral“.

Kriterien für die Methodenauswahl

Vor der Auswahl einer Methode testen Sie:

Spezifikationsreife und Governance;
Resolver- und Bibliotheksinteroperabilität;
Autorisierung für Updates und Deaktivierung;
Schlüsselrotation und -wiederherstellung;
Unterstützung historischer Zustände;
Datenschutz und Metadatenlecks;
Verfügbarkeit des Registers und Zensurrisiko;
Transaktions- oder Betriebskosten;
kryptografische Agilität;
Migration und Methodenversagen.

Ein Methodenwechsel bedeutet normalerweise die Einführung eines neuen Identifikators und einen vertrauenswürdigen Migrationspfad.

DID-Auflösung versus DID-URL-Dereferenzierung

Die DID-Auflösung nimmt eine DID und Auflösungsoptionen entgegen und gibt Folgendes zurück:

DID-Auflösungsmetadaten;
ein DID-Dokument, einen Dokumentenstrom oder kein Dokument;
DID-Dokumentmetadaten.

Der Resolver verwendet die von der Methode definierte „Lese“-Operation. DID Core definiert abstrakte Schnittstellen und gemeinsame Ergebnis-Konzepte; die methodenspezifische Kommunikation und Authentifizierung verbleiben bei der Methode.

Die DID-URL-Dereferenzierung nimmt eine vollständige DID-URL entgegen und gibt Folgendes zurück:

Dereferenzierungsmetadaten;
die identifizierte Ressource, falls verfügbar;
Inhaltsmetadaten.

Die Dereferenzierung kann zuerst die Basis-DID auflösen und dann ein Fragment, einen Dienst oder eine externe Ressource auswählen. Sie ist kein Synonym für Auflösung.

Die separate W3C DID Resolution Spezifikation entwickelt detaillierte Auflösungs- und Dereferenzierungsalgorithmen. Ihre neueste Veröffentlichung ist ein W3C Working Draft vom 24. Juli 2026, und die DID-URL-Dereferenzierung ist als risikoreiche Funktion gekennzeichnet. Sie bleibt eine Standardisierungsarbeit und ist kein Bestandteil der 2022 DID Core 1.0 Empfehlung. Daher sollten Sie den Entwurf festlegen, bevor Sie Konformität beanspruchen.

Resolver-Vertrauen und Caching

Ein Resolver ist eine Sicherheits- und Datenschutzgrenze. Er sieht angefragte Identifikatoren und kann veraltete oder manipulierte Zustände zurückgeben. Bewerten Sie:

Verifizierung der Methodenergebnisse;
Transport- und Resolver-Authentifizierung;
Cache-Aktualität und -Invalidierung;
Versions- und Zeitoptionen;
Fehlerbehandlung und Downgrade-Verhalten;
Datenschutzlecks durch Lookups;
Verhalten bei Register- oder Netzwerkausfall.

DIDs und Verifiable Credentials

DIDs und Verifiable Credentials sind komplementäre Spezifikationen, nicht dasselbe Objekt.

Eine Basis-DID kann identifizieren:

einen Aussteller von Anmeldeinformationen;
ein Subjekt von Anmeldeinformationen;
einen Inhaber.

Eine Verifizierungsmethode, die von einem Sicherungsmechanismus verwendet wird, wird stattdessen durch eine DID-URL identifiziert, üblicherweise eine DID gefolgt von einem Fragment wie #key-1.

Das W3C Verifiable Credentials Data Model 2.0 definiert Anmeldeinformationen, Präsentationen, Aussteller, Inhaber, Subjekt, Gültigkeit, Status, Schemata und Sicherungsmechanismen. Es erfordert nicht, dass jeder Identifikator eine DID ist.

Wenn eine DID für einen Aussteller verwendet wird, könnte ein Verifizierer die DID des Ausstellers auflösen, die Verifizierungsmethode des Nachweises finden und bestätigen, dass die Methode unter assertionMethod autorisiert ist. Diese kryptografische Verifizierung stellt immer noch nicht fest:

dass jede Behauptung der Anmeldeinformation wahr ist;
dass der Aussteller für diese Behauptung vertrauenswürdig ist;
dass die Anmeldeinformation aktuell oder akzeptabel ist;
dass ihr Status, Schema oder Nachweis den Richtlinien entspricht;
dass das Subjekt der Anmeldeinformation die Person ist, die sie präsentiert.

Diese Prüfungen gehören zum Sicherungsmechanismus, Statussystem, Vertrauensrahmen, Präsentationsbindung und zur Verifiziererrichtlinie.

Datenschutz- und Sicherheitsaspekte

Vermeiden Sie persönliche Daten in öffentlichen Dokumenten

DID-Dokumente können weit verbreitet repliziert werden. Veröffentlichen Sie keine Namen, staatlichen Identifikatoren, biometrischen Daten, Anmeldeinformationen oder andere persönliche Daten, nur weil das Modell erweiterbar ist. Verschlüsselung ist keine dauerhafte Lösung für dauerhaft öffentlichen Chiffretext.

Korrelation verhindern

Paarweise oder kontextspezifische DIDs können die Korrelation nur reduzieren, wenn auch andere Daten getrennt werden. Wiederverwendete Schlüssel, Dienstendpunkte, Netzwerkidentifikatoren, Anmeldeinformationen, Timing und Registeraktivitäten können angeblich separate DIDs miteinander verknüpfen.

Schlüssel rotieren und wiederherstellen

Planen Sie Kompromittierung vor dem Start. Definieren Sie Update-Autorisierung, Wiederherstellungs-Controller, Schwellenwertregeln, Rotation, Umgang mit alten Schlüsseln und Deaktivierung. Die Wiederherstellungsautorität benötigt Trennung und Audit.

Nachweiszweck validieren

Prüfen Sie nicht nur, ob eine Signatur verifiziert, sondern auch, ob die Verifizierungsmethode zum relevanten Zeitpunkt für die erforderliche Beziehung autorisiert war. Verhindern Sie die Substitution zwischen Authentifizierung, Behauptung, Vereinbarung und Fähigkeitsnutzung.

Historie sorgfältig behandeln

Ein aktuelles DID-Dokument enthält möglicherweise keinen alten Schlüssel mehr. Die Überprüfung eines historischen Nachweises kann eine von der Methode unterstützte historische Version und zuverlässige Beweise des Nachweiszeitpunkts erfordern. „Schlüssel jetzt nicht vorhanden“ und „Nachweis war nie gültig“ sind keine gleichwertigen Schlussfolgerungen.

Häufige Fehler bei der DID-Implementierung

DID Core als Blockchain-Spezifikation bezeichnen

DID Core ist technologieunabhängig. Blockchains sind eine mögliche Registerarchitektur.

Die DID als Beweis der rechtlichen Identität behandeln

Eine DID unterstützt die Identifikatorsteuerung und kryptografische Verifizierung. Eine reale Identitätsbindung erfordert separate Beweise, Ausstellererklärungen oder ein Vertrauensrahmenwerk.

Jeden gelisteten Schlüssel für jeden Zweck verwenden

Setzen Sie die explizite Verifizierungsbeziehung und den Nachweiszweck durch.

Dienstendpunkten automatisch vertrauen

Validieren Sie den Methodenzustand und wenden Sie Anwendungs-, Transport-, URL- und Inhaltssicherheit an.

Annehmen, dass alle DIDs privat oder anonym sind

Registeraktivitäten, Auflösung, wiederverwendetes Material und Dienste können dauerhafte Korrelationen offenlegen.

Eine Implementierungs-Checkliste

Bestätigen Sie vor der Produktion, dass:

die ausgewählte DID Core-Version und DID-Methodenspezifikationen festgelegt sind;
die Analyse von Identifikatoren und DID-URLs eine standardkonforme URI-Behandlung verwendet;
akzeptierte Repräsentationen und Medientypen explizit sind;
jeder Nachweis die beabsichtigte Verifizierungsbeziehung durchsetzt;
Methodenergebnisse authentifiziert und nicht von irgendeinem Resolver vertraut werden;
Caching, Versionierung, historische Verifizierung und Deaktivierung getestet werden;
für Updates, Rotation, Kompromittierung, Wiederherstellung und Migration Verfahren geübt wurden;
öffentliche Dokumente keine unnötigen persönlichen oder korrelierenden Daten enthalten;
Dienstendpunkte einer separaten Sicherheitsüberprüfung auf Anwendungsebene unterzogen werden;
Vertrauen, Status, Schema und Präsentationsprüfungen von Verifiable Credentials getrennt bleiben.

Wo DIDs auf die Identitätsprüfung treffen

DIDs können Subjekte und Verifizierungsmaterial identifizieren, führen aber keine Identitätsprüfung durch. Ein wiederverwendbares Identitätssystem benötigt immer noch zuverlässige Beweise und eine geregelte Entscheidung, bevor es Behauptungen ausstellt oder akzeptiert. Didits ID-Verifizierung kann Identitätsnachweise für eine solche Entscheidung liefern, während Wiederverwendbares KYC die Wiederverwendung einer früheren Verifizierung über teilnehmende Dienste hinweg unterstützt und als kostenlos aufgeführt ist.

Diese Produktnähe impliziert nicht, dass jede Didit-Verifizierung eine DID ist oder dass die DID-Auflösung KYC ersetzt. Aktuelle Modulpreise sind auf der Preisseite verfügbar. Die Architektur sollte die Identifikatorsteuerung, Identitätsnachweise, die Ausstellung von Anmeldeinformationen, die Präsentation und die Richtlinien der vertrauenden Partei als separate Vertrauensgrenzen beibehalten.

Häufig gestellte Fragen

Was definiert die W3C DID-Spezifikation?

Sie definiert die Syntax von DID und DID-URLs, ein gemeinsames Datenmodell, Kern-DID-Dokumenteigenschaften, Repräsentationen, Methodenanforderungen und abstrakte Auflösungs- und Dereferenzierungsschnittstellen.

Verwendet jede DID eine Blockchain?

Nein. Eine DID-Methode kann ein Ledger, eine Datenbank, ein Peer-to-Peer-System, ein dezentrales Dateisystem oder eine andere Registerarchitektur verwenden.

Was ist der Unterschied zwischen einer DID und einem DID-Dokument?

Die DID ist der Identifikator. Das DID-Dokument sind zugehörige Daten, die Controller, Verifizierungsmethoden und deren Zwecke, Dienste und andere definierte Eigenschaften beschreiben können.

Was ist der Unterschied zwischen Auflösung und Dereferenzierung?

Die Auflösung ruft ein DID-Dokument und Metadaten für eine DID ab. Die Dereferenzierung ruft die durch eine vollständige DID-URL identifizierte Ressource ab, möglicherweise nach Auflösung ihrer Basis-DID.

Ist eine DID dasselbe wie eine Verifiable Credential?

Nein. Eine DID ist ein Identifikator. Eine Verifiable Credential ist ein manipulationssicherer, maschinell überprüfbarer Satz von Behauptungen unter dem VC-Datenmodell und einem Sicherungsmechanismus. VCs können DIDs verwenden, benötigen sie aber nicht universell.

Beweist die Kontrolle einer DID, wer eine Person ist?

Nein. Es kann die Kontrolle über kryptografische oder methodenspezifische Autorität, die mit der DID verbunden ist, beweisen. Die Bindung dieser Kontrolle an eine rechtliche oder reale Identität erfordert zusätzliche Beweise oder vertrauenswürdige Behauptungen.

Kann ein DID-Dokument private Schlüssel enthalten?

Nein. DID-Dokumente enthalten öffentliches Verifizierungsmaterial oder Referenzen. Material für private Schlüssel darf nicht erscheinen und muss durch das Schlüsselverwaltungssystem des Controllers geschützt bleiben.

Primäre Referenzen

DID Core ist am nützlichsten, wenn seine Behauptung präzise bleibt. Es standardisiert Identifikatoren, Dokumente, Verifizierungszwecke, Dienste und Methodenschnittstellen. Vertrauen kommt immer noch von der Governance der Methode, der authentifizierten Auflösung, geschützten Schlüsseln, explizitem Nachweiszweck, datenschutzbewusstem Design und der Entscheidung der Anwendung, welche Beweise akzeptiert werden sollen.