Dezentrale Identität und verifiable credentials

2026-08-12

Dezentrale Identität trennt Identifizierung, Ausstellung, Speicherung und Prüfung von Nachweisen, damit kein einzelner Login-Anbieter dauerhaft das Tor zu jeder Interaktion kontrolliert. Decentralized identifiers, kurz DID, können die Kontrolle über einen Identifier zeigen; verifiable credentials, kurz VC, tragen von einem Aussteller signierte Aussagen. Das richtige Modell ist keine magische Identität im Wallet, sondern ein Vertrauensablauf: Der Issuer macht eine Aussage, der Holder speichert und präsentiert sie, der Verifier prüft Proof, Status, Kontext und Policy.

Was decentralized identity explained bedeutet

Die Suche decentralized identity explained wird verständlicher, wenn Identität in Schichten zerlegt wird. Ein DID kann über eine DID method zu einem DID document oder einer Ressource aufgelöst werden. Das Dokument beschreibt Verification Methods und Services, beweist aber allein weder Alter, Ausbildung, Beschäftigung noch Rechtsstatus. Ein VC ist etwas anderes: Claims eines Issuers über ein Subject, so verpackt, dass ein Verifier Urheberschaft und Integrität prüfen kann.

Dezentral bedeutet nicht anonym, unaufspürbar oder außerhalb der Regulierung. Ein Credential kann eng an eine reale Identitätsprüfung gebunden sein, und der Verifier muss weiterhin Zugangs-, Betrugs- oder Sanktionsregeln anwenden. Entscheidend ist, wer den Identifier kontrolliert, wer den Claim ausstellt, wer Schlüssel aktualisieren darf und welche Partei dem Ergebnis vertrauen darf.

DID, Issuer, Holder und Verifier in einem Vertrauensablauf

Der Issuer stellt den Claim auf und erzeugt das Credential. Der Holder verwahrt es in einem Wallet oder geschützten Repository und entscheidet über die Präsentation. Der Verifier erhält ein Credential oder eine verifiable presentation und prüft Schutzmechanismus, Issuer, Subject, Zeitraum, Status und Geschäftszweck. Holder und Subject sind oft dieselbe Person, aber ein Elternteil kann ein Credential über ein Kind halten oder eine Organisation ein Credential über ein Gerät.

Ein DID document kann öffentliches Verification Material auffindbar machen. Ein Data Integrity proof bindet den Nachweis an eine Methode und einen Zweck, aber eine gültige Signatur bedeutet nicht, dass jeder Claim akzeptiert werden muss. Der Verifier muss Issuer, Schema, Aktualität der Präsentation und Verhältnismäßigkeit der Offenlegung bewerten.

Der VC-Lebenszyklus von Proofing bis Presentation

Der Lebenszyklus beginnt vor der Kryptografie. Bei Registrierung und Proofing bestimmt der Issuer, welche Nachweise ausreichen und welches Assurance-Level benötigt wird. Er erstellt Claims über das Subject, fügt Typ und Gültigkeit hinzu und schützt das Credential. Das Wallet bewahrt die Kopie des Holders auf. Bei der Presentation wird sie für einen bestimmten Verifier erzeugt und kann nur ausgewählte Claims offenlegen.

Verifikation ist eine Abfolge, kein einzelner grüner Haken. Der Verifier prüft Datenmodell, Schutzmechanismus, Verification Material, Proof-Zweck, Holder-Binding, Gültigkeit und Status. Ein Credential kann kryptografisch echt, aber abgelaufen, widerrufen, von einem nicht vertrauenswürdigen Issuer oder für den Zweck ungeeignet sein. Erneuerung, Sperrung, Widerruf und Löschung sind Lebenszyklusereignisse, die eine Blockchain nicht automatisch verwaltet.

Keys, DID documents und Revocation sind getrennte Kontrollen

Ein geheimer Schlüssel ist die Signaturberechtigung. Ein öffentlicher Schlüssel prüft einen Proof, erstellt aber keinen neuen gültigen Proof. Der Issuer muss Schlüssel schützen, Verification Relationships festlegen, Kompromittierung überwachen und Rotation sowie Recovery planen. Der Holder benötigt ein sicheres Gerät, Backups und eine klare Unterscheidung zwischen einer Präsentationsanfrage und der Aufforderung, ein Wallet-Geheimnis herauszugeben.

Drei Zeitachsen dürfen nicht vermischt werden: Ein Proof hat Erstellungs- und Ablaufzeiten, ein Credential validFrom und validUntil, und eine Verification Method kann wegen einer Kompromittierung rotiert oder widerrufen werden. Credential Status ist ein eigenes Signal dafür, dass eine Berechtigung oder ein Claim nicht mehr aktuell ist. Deshalb müssen Statusmechanismus, Aktualität, Verfügbarkeit, Datenschutz und Governance geprüft werden.

Selective disclosure und die Grenze der Datenminimierung

Selective disclosure ermöglicht dem Holder eine feine Auswahl der geteilten Daten. Wenn ein Dienst nur wissen muss, ob ein Schwellenwert erreicht ist, wird das vollständige Geburtsdatum vielleicht nicht benötigt. Eine Presentation kann einen abstrakten Claim oder zero-knowledge proof statt des ursprünglichen Attributs enthalten. Die Privatsphäre hängt von Credential-Format, Cryptosuite, Wallet, Anfrage und möglicher Verknüpfung wiederholter Präsentationen ab.

DID und VC bieten nicht automatisch Datenschutz. Ein stabiler Identifier, eine wiederholte Signatur, Statusabfragen, Wallet-Telemetrie oder ein öffentliches Ledger können Korrelation ermöglichen. Datenminimierung beginnt mit der Frage: Welcher kleinste Claim ist für welche Dauer und für wen erforderlich? Persönliche Daten sollten nicht ohne Grund in ein unveränderliches öffentliches Register gelangen; Aufbewahrung und Logs müssen geschützt werden.

Wo Blockchain in self sovereign identity blockchain passt

Die Formulierung self sovereign identity blockchain kann fälschlich nahelegen, dass jeder Identitätsdatensatz on-chain liegen muss. DID Core verlangt das nicht. Eine DID method kann Distributed Ledger, Datenbank, dezentrales Dateisystem oder ein anderes vertrauenswürdiges Registry nutzen. Blockchain kann für ein öffentliches, manipulationserschwertes Protokoll von Methodenoperationen, Issuer-Vertrauensdaten, Schlüsselrotation oder kompakten Status nützlich sein.

Blockchain bringt auch Kosten und Risiken: Öffentliche Einträge lassen sich kopieren und korrelieren und schwer entfernen; Verfügbarkeit und Governance verändern sich; ein Hash beweist nicht die Richtigkeit der Quelldaten; ein unveränderlicher Anchor repariert keinen kompromittierten Issuer-Key. Persönliche Claims und große Dokumente sollten geschützt gespeichert und nur notwendige Registry-Daten veröffentlicht werden.

Issuer-, Holder-, Verifier- und Registry-Fluss für DID und verifiable credentials

Compliance und praktische Prüfliste

Identitätssysteme behalten rechtliche und operative Pflichten. Je nach Jurisdiktion und Anwendungsfall können Rechtsgrundlage, Zweckbindung, Datenminimierung, Aufbewahrung, Sicherheit, Incident Response, grenzüberschreitende Kontrollen und ein auditierbares Vertrauensmodell erforderlich sein. DID oder Blockchain heben diese Governance-Anforderungen nicht auf.

Bei einer Integration sollte man fragen: Welche DID method und welches Registry werden genutzt? Welcher Issuer ist vertrauenswürdig und wie wurde das Subject geprüft? Welche Proof-, Cryptosuite-, Key- und Presentation-Bindings gelten? Wie werden Gültigkeit, Status, Rotation, Kompromittierung und Recovery geprüft? Werden unnötige Daten verlangt? Wo werden Credentials, Logs und Statusdaten gespeichert und wie lange? Welche Policy oder Rechtsordnung erlaubt dem Verifier, sich auf den Claim zu verlassen? Verifiable credentials blockchain beschreibt Infrastrukturmöglichkeiten, keine Garantie für Wahrheit, Datenschutz oder Compliance.

Haftungsausschluss: Dieser Artikel ist Bildungsinhalt der Bitbase Academy, nur zu Informationszwecken. Er ist keine Anlage-, Handels-, Steuer- oder Finanzberatung. Krypto-Assets sind volatil — schätze dein Risiko selbst ein. Stand August 2026; maßgeblich sind die aktuellen offiziellen Informationen.