---
title: "Dezentralisierte Identität (DID)"
description: "Praxisleitfaden zu dezentralen Identifikatoren und verifizierbaren Nachweisen: Aussagekraft, Ausstellung und Präsentation sowie verbleibende Vertrauens-, Datenschutz- und Wiederherstellungsrisiken."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Dezentralisierte Identität (DID)

> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

<a id="answer"></a>

## Direkte Antwort

Dezentralisierte Identität ist eine Architektur, in der ein Subjekt dienstübergreifend Identifikatoren und kryptografisch geschützte Nachweise nutzen kann, ohne ein Plattformkonto zur universellen Identitätsquelle zu machen. Typische Bausteine sind dezentrale Identifikatoren (DIDs), verifizierbare Nachweise (VCs), Inhabersoftware wie eine Wallet und Regeln darüber, welche Aussteller, Belege und Vertrauensniveaus Prüfer akzeptieren.

Ein DID ist ein URI wie `did:example:123`. Seine DID-Methode legt fest, wie der Identifikator erstellt, aufgelöst, aktualisiert und deaktiviert wird. Die Auflösung kann ein DID-Dokument mit Verifizierungsmethoden, Beziehungen wie `authentication` oder `assertionMethod` und optionalen Dienstendpunkten liefern. Die Kontrolle des passenden Schlüssels kann die Kontrolle über den DID nach dieser Methode belegen; allein beweist sie weder amtlichen Namen, Alter, Einmaligkeit, Beschäftigung noch Eigentum an einem externen Konto.

Ein verifizierbarer Nachweis enthält Aussagen eines Ausstellers über ein oder mehrere Subjekte. Der Inhaber speichert ihn und kann eine verifizierbare Präsentation für einen Prüfer erstellen. Eine erfolgreiche kryptografische Prüfung bestätigt Integrität und Urheberschaft der geschützten Daten unter dem gewählten Verfahren. Der Prüfer muss gesondert entscheiden, ob er dem Aussteller vertraut, die Aussagen seiner Richtlinie genügen, der Nachweis aktuell ist und der Präsentierende ihn verwenden darf.

„Dezentralisiert“ bedeutet daher nicht vertrauensfrei, anonym, blockchainbasiert oder ohne Vermittler. Identifikatoren, Nachweise, Register, Wallets und Prüfregeln können getrennt werden, sodass kein einzelner Login-Anbieter jede Beziehung beobachten und kontrollieren muss. Der tatsächliche Grad hängt von Ausstellern, DID-Methodenbetreibern, Statusdiensten, Wallet-Anbietern, Wiederherstellungsstellen, Governance-Schlüsseln und Prüfrichtlinien ab.

<a id="mechanism"></a>

## Funktionsweise

1. **Aussage und Vertrauensrahmen definieren.** Subjekt, angeforderte Attribute, akzeptierte Aussteller, Prüfverfahren, Vertrauensniveau, Aufbewahrung, Rechtsraum und Beschwerdeweg sind festzulegen. Ein kryptografisches Format entscheidet nicht, ob Universität, Behörde, Arbeitgeber oder Gemeinschaft zuständig ist.
2. **Identifikatoren und Schlüssel erstellen oder beziehen.** Aussteller und Inhaber können DIDs, HTTPS-URLs oder andere unterstützte Identifikatoren nutzen. Bei einem DID bestimmt die Methode Register und Lebenszyklus. Der Controller schützt den privaten Schlüssel; das aufgelöste Dokument legt nur nötiges Verifizierungsmaterial und Endpunkte offen.
3. **Subjekt prüfen und binden.** Der Aussteller prüft Belege gemäß Richtlinie und bindet die Aussagen an ein Nachweissubjekt. Die Bindung kann auf einen vom Inhaber kontrollierten Schlüssel, ein Konto oder einen anderen Identifikator verweisen. Belege über eine Person sind von Belegen über die Schlüsselkontrolle des aktuellen Präsentierenden zu unterscheiden.
4. **Nachweis ausstellen.** Der Aussteller erstellt Aussagen, Gültigkeitsdaten, Schema- oder Typangaben und einen Statusverweis und schützt den Nachweis mit einem unterstützten Beweis. Bei Data Integrity zeigen `cryptosuite`, `verificationMethod`, `proofPurpose` und `proofValue`, wie er geprüft wird.
5. **Speichern und auswählen.** Der Inhaber hält den Nachweis in lokaler oder gehosteter Wallet-Software. Die Wallet sollte die Anfrage erklären, nur notwendige Daten offenlegen, soweit das Format dies erlaubt, und stabile Identifikatoren nicht unbemerkt in fremden Kontexten wiederverwenden.
6. **Mit Aktualität und Empfängerbindung präsentieren.** Der Prüfer sendet Identität, Zweck, Nonce oder Challenge und Ablaufzeit. Der Inhaber liefert Nachweis oder abgeleitete Präsentation gebunden an diese Anfrage. Domain- und Challenge-Prüfung erschweren die Wiederverwendung bei einem anderen Prüfer oder einer anderen Sitzung.
7. **Kryptografie und Richtlinie prüfen.** Verifizierungsmaterial des Ausstellers wird aus authentisierter Quelle aufgelöst; Suite, Zweck, Challenge, Domain, Daten, Schema und Status werden validiert; danach folgen Geschäftsregeln. `verified: true` ist eine Eingabe für die Autorisierung, kein Befehl zur Freigabe.
8. **Lebenszyklus betreiben.** Kompromittierte Schlüssel rotieren, Nachweise sperren oder widerrufen, Status aktualisieren, Wiederherstellung und Beschwerden anbieten, Auditbelege sichern und Migration oder Abschaltung planen. Historische Prüfung braucht klare Regeln für alte Schlüssel, Dokumente und Präsentationszeitpunkte.

Die drei Hauptrollen sind **Aussteller**, **Inhaber** und **Prüfer**; das Nachweissubjekt kann vom Inhaber abweichen. Eltern können einen Nachweis über ein Kind halten, Unternehmensvertreter einen über eine Organisation präsentieren. Ohne eine Bindung durch Nachweis und Protokoll darf die Implementierung nicht annehmen, der Präsentierende sei das Subjekt.

DIDs und VCs sind unabhängig. Eine VC kann einen Nicht-DID-Ausstelleridentifikator verwenden, und ein DID braucht keine VC. Eine DID-Methode kann Blockchain, verteilte Datenbank, Webdomain oder Peer-to-Peer-Austausch nutzen. Ihre Sicherheit und Governance sind direkt zu bewerten, nicht aus dem Präfix `did:` abzuleiten.

<a id="example"></a>

## Praxisbeispiel

Ein Dienst muss bestätigen, dass ein Kunde mindestens 18 ist, ohne das Geburtsdatum zu erheben. Eine akzeptierte Stelle prüft den Kunden und stellt einer Wallet einen Altersnachweis aus. Er kann das Geburtsdatum oder nur die Aussage `ageOver18` enthalten; beide Varianten haben andere Offenlegungs- und Wiederverwendungseigenschaften.

Bei der Anmeldung fordert der Dienst für `merchant.example` eine Präsentation über 18, Challenge `n-7f3a` und ein 5-Minuten-Fenster an. Die Wallet zeigt die Anfrage und leitet, falls Nachweis und Suite es erlauben, eine Präsentation nur des nötigen Prädikats ab. Der Dienst prüft Methode, Beweis, Challenge, Domain, Zeitraum und Status, bevor er das für Audits nötige Mindestergebnis speichert.

Der Ablauf verringert die Speicherung von Dokumentbildern oder vollständigen Geburtsdaten, beseitigt aber Vertrauen und Risiko nicht. Die Stelle kann die falsche Person aufnehmen; Wallet oder Gerät können kompromittiert sein; stabile Identifikatoren oder Statusabfragen können Nutzungen verknüpfen; der Dienst kann zu viele Daten verlangen; eine falsche Sperre kann Zugang verweigern. Selektive Offenlegung begrenzt Präsentationsdaten, nicht alle Metadaten für Aussteller, Wallets, Netze und Prüfer.

Schlüsselrotation zeigt eine weitere Grenze. Ersetzt der Aussteller einen kompromittierten Schlüssel, sollten neue Nachweise die neue Methode nutzen. Ob alte Nachweise prüfbar bleiben, hängt von Methodenverlauf, Beweiszeitpunkt, Prüfrichtlinie und Status ab. Das bloße Löschen des alten Schlüssels aus dem aktuellen DID-Dokument kann legitime historische Prüfungen brechen oder verbergen, welcher Schlüssel bei Beweiserstellung autorisiert war.

<a id="risks"></a>

## Risiken und Kontrollen

- **Falsche oder zu breite Aussagen:** Eine gültige Signatur bewahrt die Aussage des Ausstellers, macht sie aber nicht richtig. Belege, Haftung, Vertrauensniveau, Audit, Ablauf und Korrektur sind zu definieren.
- **Schwache Inhaberbindung:** Ein kopierter Nachweis kann fremdgenutzt werden, wenn die Präsentation nicht die Kontrolle des vorgesehenen Schlüssels oder Authenticators beweist. Besitzbeweis gegebenenfalls an Prüfer, Challenge, Zweck und Sitzung binden.
- **Schlüssel- und Wallet-Kompromittierung:** Malware, Phishing, Cloud-Wallet-Übernahme oder unsichere Backups können Nachweise und Schlüssel offenlegen. Phishing-resistente Authentisierung, angemessener Hardwareschutz, Meldung und enge Wiederherstellung sind nötig.
- **Zentralisierte Wiederherstellung:** Ein einzelner Administrator kann zum wirklichen Identitätscontroller werden. Dokumentiert werden müssen Austauschbefugnis, erforderliche Belege, Missbrauchserkennung sowie Beschwerde und Migration.
- **Korrelation:** Wiederverwendung von DID, Methode, Signaturmuster, Endpunkt oder Statuspfad kann Aktivitäten dienstübergreifend verknüpfen. Paarweise Identifikatoren, domaingetrennte Schlüssel oder Beweise, private Statusverfahren und Metadatentests helfen.
- **Öffentliche Personendaten:** DID-Dokumente und Registerhistorie können öffentlich indiziert und schwer gelöscht werden. Namen, Dokumentnummern, Biometrie und persönliche Aussagen gehören nicht in öffentliche DID-Dokumente oder unveränderliche Register.
- **Statusdatenschutz und -verfügbarkeit:** Jede Rückfrage beim Aussteller verrät den Einsatzort; Ausfälle blockieren gültige Nutzer. Datenschutzfreundliche, cachebare Statusmodelle mit Aktualitätsgrenze, authentisierten Updates und definiertem Fehlverhalten sind vorzuziehen.
- **Widerrufsmissbrauch:** Aussteller oder Administratoren können Inhaber durch Sperre oder Statusänderung zensieren. Befugnis begrenzen, Änderungen protokollieren, Gründe und Beschwerde offenlegen sowie Ersatz oder alternative Aussteller ermöglichen.
- **Auflösungs- und Methodenrisiko:** Resolver können veraltete oder bösartige Dokumente liefern; Methoden können zentraler Infrastruktur oder veränderlicher Governance folgen. Ergebnisse authentisieren und Finalität, Updatebefugnis, Verfügbarkeit, Governance und Versionierung je Methode bewerten.
- **Semantische Abweichung:** Zwei Systeme können dieselben Felder lesen und Aussage, Einheit, Rechtsraum oder Vertrauensniveau anders deuten. Stabile Schemata und Vokabulare nutzen, Kontext und Typ validieren und Richtliniensemantik versionieren.
- **Replay und Prüferverwechslung:** Eine nicht an Nonce, Empfänger, Domain, Aktion und Ablauf gebundene Präsentation kann wiederverwendet oder umgeleitet werden. Jede vom Protokoll verlangte Bindung validieren.
- **Übermäßige Offenlegung:** Trotz selektiver Offenlegung kann ein Prüfer den ganzen Nachweis fordern. Datenminimierung in Richtlinie und Oberfläche durchsetzen, Zweck erfassen und optionale Felder nicht gewohnheitsmäßig verpflichtend machen.
- **Ökosystembindung:** Proprietäre Wallets, Beweisformate, Register oder Wiederherstellung können Portabilität verhindern. Konformität, Export, mehrere Wallets, kryptografische Agilität und Migration vorab testen.
- **Governance-Übernahme:** Multisignatur oder Register garantieren keine breite Kontrolle, wenn ein Anbieter Aussteller, Updates, Schemata und Status bestimmt. Operative Befugnis komponentenweise abbilden und Änderungskontrollen veröffentlichen.

<a id="misconceptions"></a>

## Häufige Missverständnisse

- **„Ein DID beweist, wer eine Person ist.“** Ein DID identifiziert ein Subjekt und kann Methoden offenlegen; Attribute benötigen weitere Aussagen, Belege und Vertrauensentscheidungen.
- **„Ein gültiger Nachweis macht die Aussage wahr.“** Prüfung zeigt erwarteten Beweis und unveränderte Daten, nicht die Richtigkeit der ursprünglichen Untersuchung oder Beurteilung.
- **„Der Inhaber ist immer das Nachweissubjekt.“** Rollen können abweichen; nötigenfalls braucht der Prüfer eine explizite Bindung zwischen Subjekt und Präsentierendem.
- **„Alles gehört auf die Blockchain.“** Öffentliche unveränderliche Speicherung verschärft Datenschutz-, Korrelations-, Lösch- und Governance-Risiken. Viele Systeme halten Nachweise off-chain und veröffentlichen nur nötiges Prüf- oder Statusmaterial.
- **„Selektive Offenlegung garantiert Anonymität.“** Attribute, stabile Identifikatoren, Beweisfingerabdrücke, Statusabfragen, Zeitpunkte, IP-Adressen und Ausstellerprotokolle können Präsentationen verknüpfen.
- **„Dezentralisiert heißt ohne vertrauenswürdige Aussteller oder Administratoren.“** Vertrauen wird verteilt und explizit, nicht entfernt. Ausstellung, Prüfung, Wallet-Verteilung, Wiederherstellung, Status und Akzeptanz bleiben gesteuert.
- **„Ein DID entspricht einem Menschen.“** Eine Person kann viele DIDs kontrollieren; ein DID kann Organisation, Gerät, Datensatz, Rolle oder anderes Subjekt bezeichnen. Einmaligkeit und Personsein brauchen eigene Verfahren.
- **„Eine Wallet-Signatur reicht zur Authentisierung.“** Sie beweist Schlüsselkontrolle unter bestimmten Bedingungen. Anwendung braucht weiterhin Phishing-Schutz, Aktualität, Empfängerbindung, Autorisierung und Kontowiederherstellung.

<a id="related"></a>

## Verwandte Themen

- [Kryptografischer Akkumulator](/crypto/cryptographic-accumulator/)
- [Proof of Personhood](/crypto/proof-of-personhood/)
- [Sybil-Angriff](/crypto/sybil-attack/)
- [Wallet-Signatur](/crypto/wallet-signature/)
- [Zero-Knowledge-Beweis](/crypto/zero-knowledge-proof/)

<a id="sources"></a>

## Quellen

- [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-1.0/) - W3C (abgerufen: 2026-08-20)
- [Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/) - W3C (abgerufen: 2026-08-20)
- [Verifiable Credential Data Integrity 1.0](https://www.w3.org/TR/vc-data-integrity/) - W3C (abgerufen: 2026-08-20)
- [Bitstring Status List v1.0](https://www.w3.org/TR/vc-bitstring-status-list/) - W3C (abgerufen: 2026-08-20)
- [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-4/) - NIST (abgerufen: 2026-08-20)

Source: https://wiki.fcontext.com/de/crypto/decentralized-identity/index.mdx