Dezentrale Identität und verifiable credentials

2026-08-24

Dezentrale Identität trennt Identifizierung, Ausstellung von Nachweisen, Speicherung und Prüfung, damit kein einzelner Login-Anbieter dauerhaft das Tor zu jeder Interaktion kontrollieren muss. Decentralized identifiers, kurz DID, helfen einer Entität, die Kontrolle über einen Identifier nachzuweisen, während verifiable credentials, kurz VC, Aussagen tragen, die ein Aussteller signiert hat. Das nützliche Denkmodell beschreibt keine magische Identität, die einem Wallet gehört, sondern einen Vertrauensablauf: Der Issuer trifft eine Aussage, der Holder speichert und präsentiert sie, und der Verifier prüft Proof, Status, Kontext und Policy. Dieser Artikel erklärt diesen Ablauf, zeigt, wo eine Blockchain hineinpasst, und warum Schlüsselverwaltung, Widerruf, Selective Disclosure und Datenschutz unverzichtbar bleiben.

Was decentralized identity explained bedeutet

Die Phrase decentralized identity explained versteht man am leichtesten, wenn man Identität in Schichten zerlegt. Ein DID ist ein Identifier, den eine DID method zu einem DID document oder einer verwandten Ressource auflösen kann. Das Dokument kann Verification Methods, Services und die Beziehungen beschreiben, für die ein Schlüssel verwendet werden darf. Ein VC ist etwas anderes: eine Menge von Claims, die ein Issuer über ein Subject trifft und so verpackt, dass ein Verifier Urheberschaft und Integrität prüfen kann. Ein DID kann Person, Organisation, Gerät oder Dienst benennen, doch allein beweist er weder Alter noch Ausbildung, Beschäftigung oder Rechtsstatus.

Diese Trennung verhindert eine gängige Übertreibung. Dezentral bedeutet nicht anonym, nicht unauffindbar und nicht außerhalb der Regulierung. Ein Credential kann eng an ein reales Proofing gebunden sein, und ein Verifier muss oft eigene Regeln zu Berechtigung, Betrug, Sanktionen oder Zugang anwenden. Eine DID method kann außerdem von einem zentralen Dienst, einem föderierten System, einer Datenbank, einem Distributed Ledger oder einem anderen Registry abhängen. Die Entwurfsfrage lautet, wer den Identifier kontrolliert, wer den Claim trifft, wer die zugehörigen Schlüssel aktualisieren darf und welche Partei sich auf das Ergebnis stützen darf.

DID, Issuer, Holder und Verifier in einem Vertrauensablauf

Die vier Begriffe beschreiben verschiedene Aufgaben. Der Issuer ist die Behörde oder Organisation, die einen Claim behauptet und ein Credential erzeugt. Der Holder besitzt das Credential, meist in einem Wallet oder einem anderen geschützten Repository, und entscheidet, wann er es vorlegt. Der Verifier erhält ein Credential oder eine verifiable presentation und prüft Sicherungsmechanismus, Issuer, Subject, Gültigkeitszeitraum, Status und den Geschäftszweck der Anfrage. Das Subject ist die Entität, über die der Claim etwas aussagt. Holder und Subject sind oft dieselbe Person, doch ein Elternteil kann ein Credential über ein Kind halten, und eine Organisation kann Credentials über ein Gerät halten.

Ein DID document kann einem Verifier helfen, das öffentliche Verification Material zu finden, das zu einem Issuer oder Holder gehört. Data Integrity proofs können einen Nachweis an eine Verification Method und einen erklärten Zweck binden, doch eine erfolgreiche Signaturprüfung bedeutet nicht, dass jeder Claim akzeptiert wird. Der Verifier braucht weiterhin eine Vertrauensentscheidung: Ist dieser Issuer für diese Art von Claim anerkannt, passt das Credential-Schema, ist die Präsentation aktuell genug, und ist die verlangte Offenlegung verhältnismäßig? NIST beschreibt dies als Trennung der kryptografischen Verifikation von der Validierung und Bewertung der Claims.

Der VC-Lebenszyklus von Proofing bis Presentation

Der Lebenszyklus beginnt vor der Kryptografie. Bei Registrierung oder Identity Proofing entscheidet ein Issuer, welche Nachweise ausreichen und welches Assurance-Level der Anwendungsfall verlangt. Anschließend erzeugt er Claims über ein Subject, ergänzt Metadaten wie Typ und Gültigkeit und sichert das Credential mit einem kompatiblen Mechanismus. Das Wallet oder Repository schützt die Kopie des Holders. Zum Zeitpunkt der Präsentation erstellt der Holder eine Presentation für einen bestimmten Verifier, nutzt dabei ein Credential oder mehrere und legt möglicherweise nur ausgewählte Claims offen.

Verifikation ist eine Abfolge, kein einzelner grüner Haken. Ein Verifier zerlegt das Dokument, prüft Datenmodell und Sicherungsmechanismus, löst das passende Verification Material auf, validiert den Proof-Zweck und eine etwaige Holder-Bindung, prüft die Gültigkeit des Credentials und führt eine Statusprüfung durch, wenn ein solcher Mechanismus vorhanden oder per Policy gefordert ist. Erst danach bewertet er, ob Issuer und Claims die Geschäftsregel erfüllen. Ein Credential kann kryptografisch echt sein und trotzdem scheitern, weil es abgelaufen oder widerrufen ist, von einer unzuverlässigen Stelle stammt, das falsche Subject betrifft oder für den verlangten Zweck ungeeignet ist. Erneuerung, Update, Sperrung, Widerruf und schließlich Löschung sind Lebenszyklusereignisse und keine Eigenschaften, die eine Blockchain automatisch verwaltet.

Keys, DID documents und Revocation sind getrennte Kontrollen

Private oder geheime Schlüssel sind die Signaturberechtigung. Ein öffentlicher Schlüssel oder eine andere Verification Method lässt einen Verifier einen Proof prüfen, aber keinen neuen gültigen Proof erzeugen. Der Issuer muss Signaturschlüssel schützen, festlegen, welche Verification Relationship jeder Schlüssel trägt, Kompromittierung überwachen und Rotation sowie Recovery planen. Auch ein Holder braucht sicheren Gerätezugang, Backup oder Recovery und einen Weg, eine Credential-Präsentation von der Bitte um ein Wallet-Geheimnis zu unterscheiden. Ein verlorener Schlüssel kostet Zugang; ein offengelegter geheimer Schlüssel erlaubt Identitätsmissbrauch, bis das Ökosystem reagiert.

Drei Uhren dürfen nicht verwechselt werden. Ein Proof kann Erstellungs- und Ablaufzeiten haben, ein Credential kann validFrom und validUntil haben, und eine Verification Method kann rotiert, widerrufen oder ablaufen gelassen werden, weil ihr Schlüssel kompromittiert ist. Credential Status ist ein anderes Signal: Er kann anzeigen, dass die durch ein Credential dargestellte Berechtigung oder Aussage nicht mehr aktuell ist. Ein Verifier muss deshalb den Statusmechanismus und dessen Aktualität prüfen und nicht nur, ob eine Signatur mathematisch aufgeht. Statuslisten, Registries oder Issuer-Endpunkte verbessern die operative Kontrolle, brauchen aber ebenfalls Absicherung für Verfügbarkeit, Datenschutz, Integrität und Governance.

Selective disclosure und die Grenze der Datenminimierung

Selective Disclosure bedeutet, dass ein Holder fein abgestuft entscheiden kann, welche Information er teilt. Muss ein Dienst nur wissen, ob jemand eine Schwelle überschreitet, ist ein vollständiges Geburtsdatum womöglich überflüssig. Eine Presentation kann manchmal einen abstrakten Claim oder einen Zero-Knowledge-Proof statt des ursprünglichen Attributs tragen. Andere Profile nutzen Selective-Disclosure-Token oder Proof Suites. Die genaue Datenschutzeigenschaft hängt von Credential-Format, kryptografischer Suite, Wallet, Verifier-Anfrage und davon ab, ob wiederholte Präsentationen verknüpfbar sind.

Die wichtige Grenze: DID und VC liefern nicht automatisch Datenschutz. Ein stabiler Identifier, eine wiederholte Signatur, eine Statusabfrage, ein Telemetrieereignis des Wallets oder ein Eintrag in einem öffentlichen Ledger können Korrelation erzeugen. Datenminimierung beginnt deshalb bei der Frage des Verifiers: Welcher kleinste Claim wird für diese Entscheidung gebraucht, für wie lange, und wer muss ihn sehen? Entwerfende sollten personenbezogene Daten nicht in unveränderliche öffentliche Register legen, wo unterstützt paarweise oder kontextgerechte Identifier bevorzugen, Aufbewahrung verkürzen, Logs schützen und Nutzenden Gegenstelle und Zweck vor dem Teilen klarmachen. Datenschutz ist ein Ergebnis der Architektur und kein Etikett auf einem Wallet.

Wo Blockchain in self sovereign identity blockchain passt

Die Phrase self sovereign identity blockchain legt oft nahe, dass jeder Identitätsdatensatz on-chain liegen muss. DID Core verlangt das nicht. Eine DID method definiert, wie Identifier und Dokumente erzeugt, aufgelöst, aktualisiert oder deaktiviert werden; ein verifiable data registry kann Distributed Ledger, Datenbank, dezentrales Dateisystem oder ein anderes vertrauenswürdiges System sein. Eine Blockchain kann als öffentliches, manipulationssicheres Register für Methodenoperationen, Issuer-Vertrauensmetadaten, Schlüsselrotation oder kompakte Statusinfos nützlich sein. Sie erleichtert auch gemeinsames Auffinden, wenn Beteiligte das Register nicht einem einzigen Betreiber überlassen wollen.

Eine Blockchain bringt auch Kosten und Risiken. Öffentliche Einträge lassen sich kopieren, korrelieren und kaum entfernen; Transaktionsverfügbarkeit und Governance können sich ändern; ein Hash beweist nicht, dass die Ursprungsdaten korrekt waren; und ein unveränderlicher Anker repariert keinen kompromittierten Issuer-Schlüssel. Ein solider Entwurf hält persönliche Claims und große Dokumente in geschütztem Speicher, veröffentlicht nur die nötigsten Registerdaten und dokumentiert, wie Update, Recovery, Migration und rechtliche Anfragen ablaufen. Selbstsouveräne Kontrolle versteht man besser als Bündel von Fähigkeiten für Nutzende und Organisationen denn als Versprechen einer Kette, jemanden von Issuern, Verifiern oder Recht unabhängig zu machen.

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

Compliance und praktische Prüfliste

Identitätssysteme haben weiter rechtliche und operative Pflichten. Je nach Rechtsordnung und Fall braucht ein Betreiber womöglich Rechtsgrundlage, Zweckbindung, Datenminimierung, Aufbewahrungskontrollen, Auskunfts- und Berichtigungsprozesse, Sicherheit, Incident Response, Kontrollen grenzüberschreitender Übermittlung und einen auditierbaren Vertrauensrahmen. Materialien zur European Digital Identity Wallet betonen, nur die vereinbarten Informationen zu teilen, während die NIST-Leitlinien zum Identity Proofing zeigen, dass Validierung, Widerrufsprüfungen soweit verfügbar und Authentifizierungssicherheit getrennte Schritte sind. Das sind Governance-Anforderungen um ein technisches Credential und keine Funktionen, die DID oder Blockchain aufheben können.

Für eine echte Integration stellt man sieben Fragen. Welche DID method und welches Registry werden genutzt, und wie werden Auflösungsfehler behandelt? Welchem Issuer vertraut man für diesen Claim, und wie wurde das Subject geprüft? Welcher Sicherungsmechanismus, welche Cryptosuite, welche Schlüsselbeziehung und welche Präsentationsbindung sind verlangt? Wie werden Gültigkeit, Status, Rotation, Kompromittierung und Recovery kontrolliert? Verlangt die Anfrage mehr Daten, als die Entscheidung braucht, und hält die Präsentation Replay und Korrelation stand? Wo werden Credentials, Logs und Statusdaten gespeichert, und wie lange bleiben sie erhalten? Und schließlich: Welche Aufsicht, welcher Vertrag, welche Trust List oder welche interne Policy bestimmt, ob der Verifier sich auf den Claim stützen darf? Die Phrase verifiable credentials blockchain beschreibt Infrastrukturmöglichkeiten und keine Garantie für Wahrheit, Datenschutz oder Compliance.

Weiterführende Artikel

Weitere Bitbase-Artikel zu diesem Thema:

- Airdrops und Farming

- Krypto-Mixer und Privacy Pools

- Was ist Billions Network: eine datensparsame Identitätsplattform

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.