Was ist ein dezentraler Identifikator (DID)? Ein Leitfaden zur Blockchain-basierten digitalen Identität

26. Mai 2026 15 Minuten Lesezeit

Artikel mit KI zusammenfassen

Sie haben es wahrscheinlich selbst schon erlebt: Sie geben GPT ein Selfie, bitten um ein passähnliches Dokument, und innerhalb von Minuten erhalten Sie etwas, das einfache Sichtkontrollen übersteht. Wenn man dann noch Stimmenklonen und synthetische Videos hinzufügt, sieht die “Lebendigkeit” wie Theater aus. Das ist der wirkliche Durchbruch der digitalen Identität in 2026. Das fotobasierte KYC-Modell selbst nutzt sich ab. Wenn der Identitätsnachweis immer noch davon abhängt, dass Bilder schwer zu fälschen sind, bauen Sie auf Sand.

Und was bedeutet das für uns? Mit einer ziemlich offensichtlichen Verlagerung: weg von der Speicherung von Identitätsdaten und hin zur kryptografischen Überprüfung von Ansprüchen. Anstatt einen Passscan zu sammeln und in einer anderen Datenbank zu parken, fragt das System nach Beweisen: Sind Sie über 18 Jahre alt, haben Sie KYC bestanden, sind Sie für diese Transaktion zugelassen, und Können Sie das beweisen, ohne etwas anderes zu verraten?

Aber was genau ändert sich? Warum sprechen wir plötzlich über DIDs und nachprüfbare Zeugnisse?

Denn in einem DID-basierten Modell hängt das Vertrauen nicht davon ab, wie etwas aussieht. Es kommt darauf an, wer es signiert hat und ob Sie die Kontrolle darüber nachweisen können. Ein Deepfake-Selfie hilft nicht, wenn der Prüfer einen Ausweis erwartet, der von einem vertrauenswürdigen Aussteller unterzeichnet und an Ihre kryptografischen Schlüssel gebunden ist. Sie versuchen nicht mehr, “echt” auszusehen. Sie beweisen, dass Sie im Besitz eines gültigen, signierten Anspruchs sind. Bilder sind nicht mehr die Quelle des Vertrauens. Signaturen übernehmen die Rolle.

Und genau darum geht es in diesem Leitfaden: Ich zeige, wie dieses Modell funktioniert, warum es sich zum ernstzunehmenden Weg in die Zukunft entwickelt und wie Blockchain in dieses Modell passt.

Was ist ein dezentraler Identifikator (DID)?

Ein dezentraler Identifikator (DID) ist ein URI-basierter Identifikator, der über kryptografische Schlüssel gesteuert wird und nicht von einem zentralen Verzeichnis ausgegeben und verwaltet wird. Unter dem World Wide Web Konsortium (W3C) DID-Standard wird eine DID in ein DID-Dokument aufgelöst, das andere Systeme darüber informiert, wie sie Signaturen überprüfen, den Controller authentifizieren oder mit diesem Identifikator verbundene Dienstendpunkte finden können. Im Klartext: Eine DID ist nicht Ihr Profil, Ihr Reisepass oder Ihr Kontodatensatz. Es ist der Zeiger, den andere Parteien verwenden, um zu überprüfen, ob Sie einen bestimmten Identifikator und die Schlüssel dahinter kontrollieren.

Wie sich eine DID von herkömmlichen Identifikatoren unterscheidet

An dieser Stelle wird oft alles als “nur eine weitere ID” abgetan. Das ist es aber nicht.

Eine E-Mail-Adresse ist eigentlich eine Kennung im System einer anderen Person. Wenn der Anbieter das Konto sperrt, ist die Kennung praktisch weg. Eine SSN ist eine staatlich vergebene Kennung, aber sie hat keine eingebaute kryptografische Beweisebene; jeder, der die Nummer bekommt, kann sie nachspielen. OAuth-Tokens sind wieder anders: Sie sind überhaupt keine Identitätskennungen, sondern delegierte Zugriffsartefakte, die von einem Autorisierungsserver ausgegeben werden, damit ein Client eine geschützte Ressource aufrufen kann. Nützlich, ja. Tragbare Identitätsschicht, nein.

Ein DID funktioniert anders. Sie soll gelöst werden und nicht nur in einer Anbieterdatenbank nachgeschlagen werden. Die Kontrolle liegt beim Subjekt durch Schlüsselmaterial und die Regeln der DID-Methode, nicht bei einem Mail-Anbieter, einer SaaS-Plattform oder einem Identitätsbroker. Diese Unterscheidung ist in der Praxis wichtig. Wenn Sie wiederverwendbare Anmeldeinformationen, wallet-basierte Anmeldungen oder Überprüfungsabläufe entwickeln, die über Unternehmensgrenzen hinweg funktionieren sollen, bietet eine E-Mail- oder app-spezifische Benutzer-ID nicht genügend vertrauensbildende Elemente. Eine DID schon.

DID-Struktur: did:method:identifier

Auf der Ebene der Syntax ist das W3C-Modell einfach: Ein DID besteht aus drei Teilen: dem DID-Schema, einem Methodennamen und einem methodenspezifischen Bezeichner. Mit anderen Worten: did:methode:bezeichner.

Ein Beispiel ist did:web:beispiel.de als ein konkretes Beispiel.

hat sagt Ihnen, dass dies ein dezentraler Identifikator ist
Web sagt Ihnen, welche DID-Methode Auflösungsregeln definiert
Beispiel.com ist der methodenspezifische Bezeichner

Mit tat:web, Die Auflösung bezieht sich in der Regel auf ein DID-Dokument, das an einem bekannten HTTPS-Standort auf dieser Domäne veröffentlicht wird. Mit etwas wie tat:ethr, Die Auflösung hängt von den Regeln für Ethereum-verknüpfte Methoden ab. Gleiche DID-Syntax, anderes Vertrauens- und Aktualisierungsmodell.

Das ist der springende Punkt: die DID-Zeichenkette selbst ist nur das Handle. Die Methode sagt Ihnen, wie Sie sie auflösen können. Das DID-Dokument liefert Ihnen das Prüfmaterial. Sobald Sie dieses erhalten haben, können Sie Unterschriften überprüfen, einen Inhaber authentifizieren oder eine Berechtigungsnachweispräsentation validieren ohne die Kennung als eine weitere Zeile in einer Benutzertabelle zu behandeln.

Brieftasche und Präsentationsprotokolle

Bis jetzt haben wir DIDs und überprüfbare Ausweise als Datenstrukturen betrachtet: Identifikatoren, Dokumente, Unterschriften. Aber das ist nur ein Teil eines funktionierenden Identitätssystems. In realen Anwendungen ist das schwierigere Problem die Interaktion: Wie werden Ausweise ausgestellt, wie werden sie präsentiert, und wie entscheiden die Prüfer, ob sie ihnen vertrauen.

In Produktionssystemen wie dem EU-Geldbörse für digitale Identität oder US-Mobilführerschein (mDL) Piloten, Geldbörsen und Verifizierer lösen nicht einfach einen DID auf und machen damit Schluss. Sie kommunizieren über definierte Protokolle und Berechtigungsformate:

ISO/IEC 18013-5 (mdoc): ein standardisiertes Format für mobile Ausweise wie z. B. Führerscheine, das für die Darstellung von Gerät zu Gerät und auf QR-Basis optimiert ist
OpenID4VP (überprüfbare Präsentationen): legt fest, wie eine Brieftasche einem Prüfer die Anmeldedaten präsentiert
OpenID4VCI (überprüfbare Ausstellung von Berechtigungsnachweisen): definiert, wie Berechtigungsnachweise für eine Brieftasche ausgestellt werden
Vertrauensregister (z. B. VICAL): festlegen, welche Emittenten und Schemata eine Prüfstelle akzeptieren soll

Der wichtige Unterschied besteht darin, dass DIDs und überprüfbare Bescheinigungen Folgendes definieren was überprüft wird. Diese Protokolle definieren wie in realen Systemen zwischen Emittent, Inhaber und Prüfer bewegt.

Ohne diese Schicht bleiben die DIDs ein Auflösungsmechanismus. Mit ihr werden sie Teil einer funktionierenden Identitätsinfrastruktur.

Andere Dienstleistungen, die wir anbieten

Was ist dezentralisierte Identität?

Dezentralisierte Identität ist ein Modell, bei dem Identifikatoren, Berechtigungsnachweise und Überprüfungsabläufe nicht von einem einzigen Anbieter kontrolliert werden. Stattdessen ist die Identität in kryptografischen Schlüsseln (über DIDs) verankert, und Behauptungen über diese Identität werden unabhängig davon, wo sie verwendet werden, ausgegeben und überprüft. Eine nützliche Art, darüber nachzudenken: Die Identität ist nicht länger ein Konto, das in der Datenbank eines anderen gespeichert ist, sondern wird zu einer Reihe von überprüfbaren Angaben, die Sie kontrollieren und wiederverwenden können.

Vergleichen wir das mit den Modellen, mit denen Sie bereits arbeiten.

Dezentralisierte Identität vs. zentralisierte Identität

Die zentralisierte Identität ist immer noch überall der Standard. Eine Plattform ist Eigentümer des Benutzerdatensatzes, speichert Ihre Daten und fungiert als Autorität für die Überprüfung. Wenn Sie Zugang wünschen, authentifizieren Sie sich bei diesem System. Alles, einschließlich Anmeldung, Berechtigungen und Wiederherstellung, läuft über dieses System.

Das Problem ist nicht nur die Sicherheit (obwohl es immer wieder zu Sicherheitsverletzungen kommt). Es ist die Architektur:

Die Identität wird in verschiedenen Systemen dupliziert
Jedes System wird zu einem Honeypot für sensible Daten
Überprüfung erfordert Zugang zu internen Aufzeichnungen

Die dezentrale Identität kehrt dies um. Das System braucht Ihre Daten nicht zu speichern. Es muss nur die von Ihnen vorgetragenen Behauptungen verifizieren. Das Vertrauen verlagert sich von “wir haben Ihre Daten” zu “wir können diesen kryptografischen Beweis verifizieren”.”

Dezentralisierte Identität vs. föderierte Identität

Föderierte Identitäten (OAuth, SAML, OpenID Connect) versuchten, die Fragmentierung zu lösen, indem sie Identitätsanbieter wie Google, Microsoft oder Apple einführten, die sich für Benutzer über Dienste hinweg verbürgen.

Das funktioniert, bis zu einem gewissen Grad. Aber die föderierte Identität hat immer noch eine zentrale Abhängigkeit:

Der Identitätsanbieter kontrolliert den Zugang
Token werden über diesen Anbieter ausgegeben und validiert.
Wenn der Provider den Zugang widerruft, bricht Ihre Identität in den nachgelagerten Systemen zusammen.

Die dezentrale Identität beseitigt diese Abhängigkeit. Es gibt keinen einzelnen Emittenten, der zum Zeitpunkt der Überprüfung online sein muss. Berechtigungsnachweise werden über Signaturen verifiziert, nicht über API-Aufrufe. Das bedeutet:

Keine Laufzeit-Abhängigkeit vom Emittenten
Kein einzelner Fehlerpunkt
Berechtigungsnachweise können ohne enge Kopplung über Domänen hinweg wiederverwendet werden

Es ist eher so, wie es bei physischen Ausweisen funktioniert: Sie rufen nicht jedes Mal beim Passamt an, wenn jemand Ihren Ausweis überprüft.

Erkunden Sie die DID-Implementierung für Ihr Unternehmen

Dezentralisierte Identität vs. selbstverwaltete Identität (SSI)

Diese Begriffe werden oft durcheinander gebracht. SSI ist eher eine Design-Philosophie: Der Einzelne kontrolliert seine Identität, wählt aus, was er teilen möchte, und ist nicht an einen Anbieter gebunden. Dezentrale Identität ist der technische Stack, der das möglich macht:

DIDs für Identifikatoren
Überprüfbare Nachweise für Ansprüche
Brieftaschen zur Aufbewahrung und Präsentation

Sie können dezentrale Identitätssysteme implementieren, die nicht vollständig “selbstverwaltet” sind (z. B. von Unternehmen kontrollierte Geldbörsen oder Netzwerke mit Berechtigungen). Und man kann über SSI sprechen, ohne die Infrastruktur zu spezifizieren. In realen Systemen konvergieren die beiden Begriffe in der Regel, aber es ist sinnvoll, die Unterscheidung bei der Entwicklung von Architekturen deutlich zu machen.

Schlüsselverwaltung und Wiederherstellung

Wallets sind der Ort, an dem dezentralisierte Identität auf reale Zwänge trifft. Theoretisch liegt die Kontrolle über die Identität in der Kontrolle der kryptografischen Schlüssel. In der Praxis stellt dies ein Problem dar, das traditionelle Systeme nicht haben: Was passiert, wenn der Benutzer den Zugang verliert?

Wenn ein DID an einen privaten Schlüssel gebunden ist und dieser Schlüssel verloren geht, gibt es keinen Standard-Wiederherstellungsmechanismus. Es gibt keinen “Passwort zurücksetzen”-Fluss, es sei denn, das System ist ausdrücklich dafür ausgelegt. Der Verlust des Schlüssels kann den Verlust der Kontrolle über die Kennung und die an sie gebundenen Anmeldedaten bedeuten.

Aus diesem Grund werden bei Produktionssystemen zusätzlich zur DID-Schicht Wiederherstellungs- und Verwahrungsmodelle eingeführt:

Soziale Erholung: der Zugang kann durch vertrauenswürdige Parteien (“Wächter”) wiederhergestellt werden, was häufig über intelligente Konten und Kontoabstraktionsstandards wie ERC-4337 (und neue Vorschläge wie EIP-7702) erfolgt
MPC-Geldbörsen: private Schlüssel werden auf mehrere Geräte oder Dienste aufgeteilt, wodurch das Risiko eines einzelnen Ausfallpunkts verringert wird (verwendet in Systemen wie Fireblocks oder Web3Auth)
Hardware- und Passkey-gestützte Geldbörsen: Schlüssel werden in sicheren Hardware-Umgebungen wie iOS Secure Enclave oder Android StrongBox gespeichert, mit biometrischer oder passkey-basierter Authentifizierung

Der Kompromiss ist unvermeidlich: Je mehr Kontrolle der Benutzer erhält, desto mehr Verantwortung geht auf die Schlüsselverwaltung über. Aus diesem Grund wird in der Praxis meist ein Gleichgewicht zwischen Selbstbestimmung und Benutzerfreundlichkeit hergestellt, anstatt dem Benutzer die volle Kontrolle über die Schlüssel zu übertragen.

Die Grundprinzipien der dezentralisierten Identität

Es lohnt sich, an dieser Stelle innezuhalten, denn die DID-basierte Identität wird erst dann wirklich verständlich, wenn man ihre Kernprimitive trennt. Der Identifikator ist nicht der Berechtigungsnachweis, der Berechtigungsnachweis ist nicht die Brieftasche, und der On-Chain-Marker ist nicht die Identität selbst. Jede Ebene hat eine eigene Funktion, und diese Trennung macht das Modell erst funktionsfähig.

DIDs und DID-Dokumente. Die Auflösungsschicht. Eine DID verweist auf ein Dokument, das öffentliche Schlüssel und Prüfmethoden enthält. Wenn eine Prüfstelle eine DID sieht, verwendet sie diese, um Signaturen zu prüfen oder den Inhaber zu authentifizieren. Keine Datenbankabfrage, nur Schlüsselauflösung.
Überprüfbare Berechtigungsnachweise (VCs). Die Forderungsebene. Eine VC ist eine signierte Erklärung eines Emittenten: “Dieser Benutzer hat die KYC-Prüfung bestanden”, “Diese Brieftasche gehört einer lizenzierten Einrichtung” usw. Der Inhaber speichert sie, legt sie bei Bedarf vor, und der Verifizierer prüft die Signatur. Der Emittent muss zur Laufzeit nicht angerufen werden.

Diese beiden Komponenten bilden den Kern des dezentralen Identitätsmodells. In einigen Systemen, insbesondere in Web3-Umgebungen, werden zusätzliche On-Chain-Mechanismen verwendet, um den Zugang oder die Rollen durchzusetzen.

Seelengebundene Spielsteine (SBTs) sind ein Beispiel. Sie sind nicht übertragbare Token, die an eine Wallet gebunden sind und für Dinge wie KYC-Gating, Akkreditierung oder Protokollberechtigungen verwendet werden. Intelligente Verträge können sie direkt überprüfen.

SBTs sind jedoch nicht Teil des Identitätsstapels selbst. Sie sind eine optionale Durchsetzungsschicht, die auf Identitätssignalen aufbaut, und sie bringen Nachteile mit sich: öffentliche Sichtbarkeit in der Kette, begrenzte Übertragbarkeit und Herausforderungen im Zusammenhang mit Widerruf und Schlüsselwiederherstellung.

Warum herkömmliche Identitätssysteme versagen

Herkömmliche Identitätssysteme scheitern, weil sie Vertrauen als ein Speicherproblem behandeln. Jede Plattform sammelt die gleichen Rohdaten, wie z. B. Scans von Reisepässen, Selfies und Adressnachweisen, und speichert sie dann innerhalb ihres eigenen Compliance-Bereichs. Dadurch entsteht überall das gleiche Chaos: doppelte personenbezogene Daten, schwache Übertragbarkeit, große Angriffsflächen und Onboarding-Prozesse, die immer komplizierter werden, ohne viel besser zu werden.

Risiken für Sicherheit und Datenschutzverletzungen

Im traditionellen Modell kumulieren Identitätssysteme mit der Zeit Risiken. KYC-Anbieter, Börsen, Fintech-Apps, HR-Plattformen und Marktplätze speichern am Ende alle in etwa die gleichen Nachweise: Personalausweis, Gesichtsscan, Adressdaten und Metadaten aus der Verifikationssitzung selbst.

Vom Standpunkt der Implementierung aus betrachtet, wird das Problem in der Regel durch die Verbreitung von Kopien noch verschärft. Dieselben Benutzerdaten landen in Onboarding-Systemen, Betrugs-Tools, CRM-Ebenen, Support-Tools, Data Warehouses und Compliance-Archiven. Selbst wenn der primäre Verifizierungsstapel gesperrt ist, gelten für die umliegenden Systeme oft nicht die gleichen Standards.

Mangelnde Kontrolle und Eigenverantwortung der Nutzer

Bei der herkömmlichen Identität hat der Nutzer fast keine Kontrolle über den Überprüfungsstatus. Die Plattform kontrolliert den Datensatz, die Aufbewahrungsrichtlinie, den Zeitplan für die erneute Überprüfung und die Regeln für die Wiederverwendung.

Das bedeutet, dass der Nutzer kein Vertrauen von einem Kontext in einen anderen übertragen kann. Das Bestehen der KYC-Prüfung auf Plattform A bringt auf Plattform B nichts, da das Prüfergebnis innerhalb des Konformitätsbereichs von Plattform A gefangen ist. Die zugrunde liegende Behauptung mag immer noch gültig sein, aber es gibt kein übertragbares kryptografisches Artefakt, auf das sich der nächste Prüfer verlassen kann.

An dieser Stelle beginnt das Modell wirtschaftlich zu scheitern. Jede Plattform muss das Vertrauen von Grund auf neu aufbauen, da die Identität als interne Daten gespeichert und nicht als wiederverwendbarer Nachweis ausgegeben wird.

Fragen des Datenschutzes und der Nachverfolgung

Auch das alte Modell gibt standardmäßig zu viel preis. Um einen engen Sachverhalt zu beweisen, werden die Nutzer in der Regel aufgefordert, das vollständige Quelldokument dahinter offenzulegen.

Das ist ein schlechtes Datenschutzmuster, aber auch ein schlechtes Systemmuster. Sobald die Identität an kontobasierte Datensätze und die wiederholte Vorlage von Dokumenten gebunden ist, wird die Korrelation über Dienste, Sitzungen und Gegenparteien hinweg einfach. Die Prüfstelle erhält mehr Daten, als sie benötigt, speichert mehr, als sie sollte, und erhöht die Haftung, ohne die Qualität des Vertrauens proportional zu verbessern.

Unzulänglichkeiten bei der Überprüfung und Einarbeitung

Dies ist die operative Steuer, die jeder bereits kennt. Dieselbe Person füllt KYC immer wieder aus, weil jede Plattform ihren eigenen Trust-Stack betreibt und die Verifizierung nicht als übertragbare Berechtigung nutzen kann.

Wenn Sie sich mit Tokenisierung, Onboarding von Börsen oder regulierten Wallet-Flows beschäftigt haben, wissen Sie, wie verschwenderisch dies ist. Der Engpass ist die Tatsache, dass Vertrauen nicht sauber zwischen Systemen übertragen werden kann, sodass jede Institution die gleiche Verifizierungspipeline um ihre eigene Datenbankgrenze herum aufbaut.

Und auch überprüfbare Beglaubigungen allein helfen da nicht weiter. Eine gültige Unterschrift beweist nur, dass eine Forderung von einer bestimmten Partei ausgestellt wurde. Sie beweist nicht, dass diese Partei die Befugnis hatte, diese Forderung auszustellen. Das ist der Teil, den viele DID-Piloten unterschätzen. Die Prüfer müssen wissen, welche Aussteller legitim sind, welche Schemata für Berechtigungsnachweise akzeptiert werden und nach welchen Regeln man sich auf eine Forderung verlassen kann.

In der Produktion wird dies durch Trust-Frameworks gehandhabt: eIDAS 2.0 Vertrauenslisten in der EU, VICAL-Stil Vertrauenskoordination für mobile Führerscheine nach ISO 18013-5, OpenID-Föderation Treuhandketten und nationale Register der Vertrauensdiensteanbieter.

Ohne diese Schicht erhalten Sie keine wiederverwendbare Identität. Sie erhalten Berechtigungsnachweise, die zwar mathematisch verifiziert sind, aber in der Praxis nichts bedeuten. Die Signatur ist gültig. Aber es fehlt das Vertrauen.

"Warum funktioniert das dezentralisierte Identitätsmodell? Weil jede Partei weniger zu speichern hat, weniger preisgeben muss und weniger nachprüfen muss. Der Benutzer kann vertrauenswürdige Nachweise wiederverwenden, der Prüfer erhält nur den Anspruch, den er benötigt, und die Plattform wird nicht zu einem weiteren PII-Tresor. Bei Innowise bedeutet das in der Regel Off-Chain-Zugangsdaten für die Portabilität, On-Chain-Bescheinigungen für die Zugangskontrolle und selektive Offenlegung für datenschutzrelevante Prüfungen."

Andrew Nalichaev

Blockchain-Experte und DeFi-Analyst

Wie dezentrale Identifikatoren und überprüfbare Berechtigungsnachweise funktionieren

Genug mit den Definitionen. Was hier zählt, ist der Verifizierungspfad: wie eine DID auflösbar wird, wie ein Aussteller einen Anspruch an sie bindet und wie dieser Anspruch später überprüft wird, ohne auf ein zentrales Register zurückzugreifen. Schauen wir uns den Ablauf einmal von vorne bis hinten an.

Die DID wird erstellt und aufgelöst

Eine DID wird erst dann nützlich, wenn sie aufgelöst werden kann. Sie wird mit Schlüsselmaterial erzeugt und gemäß einer DID-Methode veröffentlicht. Bei der Auflösung wird das DID-Dokument zurückgegeben, das die öffentlichen Schlüssel und Überprüfungsmethoden offenlegt, die andere zur Validierung von Signaturen verwenden.

Der Emittent bindet eine Forderung an den DID

Sobald das Subjekt einen DID hat, kann ein Aussteller einen signierten Anspruch als überprüfbaren Berechtigungsnachweis mit ihm verbinden. Der Aussteller führt zunächst seine Überprüfungen durch und signiert dann eine Bescheinigung, die den Anspruch mit dem Identifikator des Subjekts verknüpft. Es handelt sich also nicht um einen Rohbeweis, sondern um ein bescheinigtes Ergebnis.

Der Inhaber legt den Antrag vor

Der Inhaber bewahrt den Berechtigungsnachweis auf, in der Regel in einer Brieftasche, und legt ihn vor, wenn ein Nachweis erforderlich ist. Je nach Stack kann dies der vollständige Berechtigungsnachweis oder ein abgeleiteter Nachweis sein. Der Punkt ist die Wiederverwendung: Der Inhaber legt einen bereits verifizierten Anspruch vor, anstatt das Onboarding neu zu starten.

Der Prüfer validiert sie lokal

Die Prüfstelle prüft die Signatur des Ausstellers, bestätigt die Subjektbindung und bewertet den Status der Berechtigung, z. B. Ablauf oder Widerruf. Zu diesem Zweck löst er die DID des Ausstellers auf und ruft den öffentlichen Schlüssel aus dem DID-Dokument ab. Ein Rückruf des Ausstellers ist nicht erforderlich.

01 Die DID wird erstellt und aufgelöst

02 Der Emittent bindet eine Forderung an den DID

03 Der Inhaber legt den Antrag vor

04 Der Prüfer validiert sie lokal

Öffentliche und private (paarweise) DIDs und Schlüsselverwaltung

Sobald der Ablauf klar ist, stellen sich die eigentlichen Designfragen: Wie werden die Identifikatoren verwendet und wie werden die Schlüssel im Laufe der Zeit verwaltet?.

Eine öffentliche DID stabil und auffindbar ist. Die Aussteller verwenden es in der Regel, weil die Prüfer eine einheitliche Methode zur Auflösung von Schlüsseln und zur Validierung von Signaturen benötigen. Ein paarweiser DID hingegen wird pro Beziehung erstellt. Ein und derselbe Benutzer gibt verschiedenen Prüfern unterschiedliche Identifikatoren, was eine dienstübergreifende Korrelation verhindert.

Diese Entscheidung ist nicht kosmetisch. Die Wiederverwendung einer einzigen DID über Dienste hinweg macht die Verknüpfung trivial. Paarweise DIDs unterbrechen diese Verknüpfung auf der Ebene der Kennung.

Dann ist da noch die Schlüsselverwaltung, mit der die meisten Systeme in der Produktion Probleme haben. Ein DID ist nur so zuverlässig wie die Schlüssel, die ihm zugrunde liegen, also muss man das einplanen:

Schlüsselrotation ohne Ungültigmachen bestehender Berechtigungsnachweise
Wiederherstellungsmechanismen, wenn ein Inhaber den Zugang zu seiner Brieftasche oder seinem Gerät verliert
Schlüsseltrennung, bei der Authentifizierungsschlüssel und Schlüssel zur Bestätigung von Berechtigungen unterschiedlichen Zwecken dienen

In der Praxis ist dies der Punkt, an dem die Komplexität liegt. Die Überprüfung von Signaturen ist einfach. Die Identifikatoren brauchbar, wiederherstellbar und im Laufe der Zeit nicht korrelierbar zu halten, ist das schwierigere technische Problem.

Entwickeln Sie DID-basierte Anwendungen mit unseren Blockchain-Experten

DID-Dokumente, -Methoden und -Infrastruktur

Sobald man den Fluss hinter sich gelassen hat, stellt sich die Frage, wie die Identifikatoren tatsächlich aufgelöst und gepflegt werden. Dabei geht es um zwei Dinge: implementieren DID-Dokumentenstruktur zugänglich zu machen und implementieren DID-Methode die definiert, wie sie erstellt, aktualisiert und aufgelöst wird.

Schlüsselelemente eines DID-Dokuments

Ein DID-Dokument ist die Auflösungsausgabe eines DIDs. Es teilt den Überprüfern mit, welche Schlüssel, Kontrolleure und Dienstendpunkte für diesen Identifikator autorisiert sind. In der Praxis handelt es sich nicht um ein Benutzerprofil. Es ist ein Verifikationsdeskriptor.

Kernbereiche, die Sie normalerweise interessieren:

ID: Die DID, die das Dokument beschreibt, zum Beispiel, did:web:beispiel.de.
Controller: Die Entität, die Änderungen an dem DID-Dokument vornehmen darf. In einfachen Konstellationen kontrolliert sich die DID selbst. In Unternehmenskonfigurationen kann die Kontrolle delegiert oder aufgeteilt werden.
Überprüfungsmethoden: Öffentliche Schlüssel und ihre Typen, z. B. Ed25519, secp256k1 oder JsonWebKey2020. Diese werden zur Überprüfung von Signaturen verwendet.
Authentifizierung: Welche Überprüfungsmethoden können die Kontrolle über die DID nachweisen, z. B. bei Login- oder Challenge-Response-Flows?.
Behauptungsmethoden: Welche Schlüssel dürfen überprüfbare Berechtigungsnachweise signieren, wenn der DID als Aussteller fungiert.
Dienst-Endpunkte: Optionale Verweise auf Off-Chain-Dienste wie den Austausch von Anmeldeinformationen, Nachrichtenübermittlung oder Statusregistrierungen.

Und der Punkt der Schlüsselimplementierung bleibt derselbe: Ein Überprüfer löst die DID auf, wählt die geeignete Überprüfungsmethode aus und prüft, ob der Schlüssel für die ausgeführte Operation zugelassen ist.

Organisatorische DIDs und Delegation

Bislang haben wir vor allem über Identität als etwas gesprochen, das eine Person kontrolliert. In B2B-Systemen ist das Schlüsselsubjekt oft eine Organisation. Banken, Logistikanbieter und RWA-Plattformen müssen nicht nur die Identität wer etwas unterschrieben hat, sondern ob diese Person befugt war, für ein Unternehmen zu handeln.

An dieser Stelle werden organisatorische DIDs komplexer. Die Kontrolle ist über Rollen, Verwahrungssysteme, Unterzeichnungsrichtlinien und Delegationsregeln verteilt. In einer Produktionseinrichtung muss festgelegt werden, wer signieren darf, was er signieren darf und wie diese Berechtigung widerrufen wird.

In der Praxis kann dies bedeuten vLEI von GLEIF für die Identität von juristischen Personen, Firmenbrieftaschen mit HSM-gestützte Unterzeichnung, und Berechtigungsfähigkeitsketten wie ZCAP-LD.

Aktualisierungen und Schlüsselrotation

DID-Dokumente sind nicht statisch. Schlüssel laufen ab, Geräte gehen verloren, die Signierinfrastruktur ändert sich, und die Schlüssel des Ausstellers müssen ausgetauscht werden. Ein seriöser DID-Entwurf muss damit umgehen können, ohne dass bestehende Berechtigungsnachweise zerstört werden.

Schlüsselrotation bedeutet in der Regel das Hinzufügen einer neuen Verifizierungsmethode, das Ändern des Schlüssels, der für eine bestimmte Beziehung autorisiert ist, und das Zurückziehen des alten Schlüssels. Aber das entscheidende Detail ist Zweck. Drehen einer Authentifizierung Taste wirkt sich auf den Login- oder Challenge-Response-Flow aus. Das Drehen eines assertionMethod Schlüssel die Ausstellung und Überprüfung von Berechtigungsnachweisen beeinflusst.

Der Aktualisierungspfad hängt von der DID-Methode ab. Mit tat:web, aktualisieren Sie das gehostete DID-Dokument. Mit tat:ethr, veröffentlichen Sie eine Transaktion in der Registrierung. Der schwierige Teil ist die Kontinuität: Die Überprüfer müssen wissen, welcher Schlüssel gültig war, als eine Berechtigung ausgestellt wurde, und ob diese Berechtigung inzwischen widerrufen wurde, abgelaufen ist oder ersetzt wurde.

Und das bringt uns zu den DID-Methoden, denn die Methode definiert genau, wie Erstellung, Auflösung, Aktualisierung und Deaktivierung im realen System funktionieren.

Was ist eine DID-Methode?

Eine DID-Methode ist die Implementierungsschicht hinter der DID-Standardsyntax.

Sie definiert die Regeln für:

Wie eine DID erstellt wird
Wie es in ein DID-Dokument aufgelöst wird
Wie Aktualisierungen und Deaktivierungen gehandhabt werden

Mit anderen Worten, die DID-Syntax ist Standard (did:methode:bezeichner), aber die Methode prägt das gesamte Infrastrukturmodell hinter dem DID.

Diese drei Methoden decken die meisten Anwendungsfälle in der Praxis ab:

Modell der Auflösung

Deterministisch (abgeleitet vom öffentlichen Schlüssel)

HTTPS (bekannter DID-Dokumentenpfad)

Ethereum DID-Register (auf der Kette)

Modell aktualisieren

Nicht aktualisierbar

Außerhalb der Kette (in der Domäne gehostet)

On-chain-Transaktionen

Vertrauensmodell

Direkte Tastensteuerung

DNS + TLS + Domänenkontrolle

Blockchain-Konsens (Ethereum)

Typischer Anwendungsfall

Kurzlebige IDs, Peer-DIDs, Tests

Unternehmen, SaaS, Emittenten-DIDs

Web3, Tokenisierung, On-Chain-Identität

Die Wahl der richtigen DID-Methode

Die Tabelle zeigt Ihnen die Mechanik. Der schwierigere Teil ist die Entscheidung, mit welchem Ausfallmodus Sie leben können: DNS-Abhängigkeit, Kettenkosten, keine Rotation, öffentliche Überprüfbarkeit oder schwächere Übertragbarkeit. Hier ist also meine Meinung zur Auswahl.

Nutzen Sie die tat:web für Unternehmensemittenten, SaaS-Produkte und regulierte Arbeitsabläufe, bei denen die Domänenkontrolle bereits Teil des Vertrauensmodells ist. Es ist kostengünstig im Betrieb, leicht zu überwachen und verträgt sich gut mit der vorhandenen Infrastruktur.
Nutzen Sie die tat:ethr wenn die Identität von intelligenten Verträgen, Token-gesteuerten Abläufen, On-Chain-KYC oder Tokenisierungslogik genutzt werden muss. Sie zahlen mehr für Gas und Latenzzeit, aber Sie erhalten eine kettenbasierte Überprüfbarkeit.
Nutzen Sie die hat:Schlüssel für kurzlebige Identifikatoren, Testumgebungen, Peer-to-Peer-Ströme oder Fälle, in denen Sie keine Rotation benötigen. Sie ist sauber und übertragbar, eignet sich aber nicht für eine dauerhafte Emittentenidentität.

Bevor Sie sich entscheiden, sollten Sie die unangenehmen Fragen zur Produktion stellen:

Wer kann das DID-Dokument aktualisieren?
Was passiert, wenn der Signierschlüssel kompromittiert wird?
Können Prüfer nach der Rotation noch alte Berechtigungsnachweise validieren?
Stellt die öffentliche Auflösung ein Risiko für die Privatsphäre dar?
Erfolgt die Überprüfung off-chain, on-chain oder beides?

Bei realen Einsätzen werden in der Regel verschiedene Methoden verwendet. Emittenten verwenden oft tat:web oder tat:ethr; Die Inhaber verwenden paarweise oder ephemere Kennungen. Durch diese Aufteilung bleibt das Vertrauen der Emittenten stabil, während das Korrelationsrisiko für die Nutzer verringert wird.

Sprechen Sie mit uns über dezentralisierte Identitätsarchitektur

Welche Rolle spielt die Blockchain bei der dezentralen Identität?

Um es gleich vorweg zu nehmen: Sie brauchen keine Blockchain, um eine dezentrale Identität zu implementieren. Die DID-Core-Spezifikation des World Wide Web Consortium erfordert sie nicht, und viele Produktionssysteme laufen komplett ohne Blockchain.

Warum ist die Blockchain also überhaupt im Gespräch? Weil sie ein bestimmtes Problem wirklich gut löst: gemeinsames Vertrauen ohne einen zentralen Eigentümer. Nicht die Speicherung, nicht die Identität selbst, sondern die Koordinierung von Schlüsseln, Identifikatoren und Status.

Blockchain als Vertrauensschicht und Verankerungsschicht

In DID-basierten Systemen fungiert die Blockchain als öffentliches, manipulationssicheres Register. Je nach Methode kann es verwendet werden, um:

Anker-DIDs
DID-Dokumente veröffentlichen oder aktualisieren
Schlüssel des Ausstellers registrieren
Führen von Verfalls- oder Statusregistern

Der entscheidende Punkt: Die Blockchain verifiziert nicht die Identität. Sie bietet eine gemeinsamer Bezugspunkt auf die sich die Prüfer verlassen können, ohne einer einzigen Partei zu vertrauen.

Zum Beispiel, mit tat:ethr, wird die DID anhand der Daten auf der Kette aufgelöst. Die Prüfstelle vertraut dem Zustand der Kette, nicht der Infrastruktur des Ausstellers.

Was wird auf der Kette und was außerhalb der Kette gespeichert?

Dies ist der Punkt, an dem viele DID-Implementierungen scheitern. Blockchain ist nützlich für die gemeinsame Nutzung von Daten, aber sie ist ein schrecklicher Ort für rohe Identitätsdaten. Pässe, biometrische Daten, vollständige Anmeldeinformationen oder persönliche Daten werden nicht in die Kette aufgenommen. Sie verwenden die Kette für Beweismaterial und Koordinationsdaten und halten dann sensible Identitätsdaten außerhalb der Kette.

Ein sauberer Split sieht in der Regel wie folgt aus:

On-chain:

Kennungen oder Registrierungseinträge
Öffentliche Schlüssel oder Schlüsselhashes
Berechtigungsstatus, z. B. Sperrvermerke oder Statusverzeichnisse
Hashes oder Verweise auf Off-Chain-Datensätze

Off-Chain:

Überprüfbare Zeugnisse
Persönliche Daten
KYC-Dateien und Nachweise
Biometrische Daten
Vollständige DID-Dokumente in Methoden wie tat:web

Der Grund dafür ist einfach: Datenschutz und Kosten. Blockchains sind öffentlich, permanent und kostspielig zu aktualisieren. Identitätsdaten benötigen Datenschutz, Löschung, Korrektur und Zugangskontrolle. Diese beiden Aspekte passen nicht zusammen.

Verankerung und Unveränderlichkeit

Die Blockchain wird in der Regel zur Verankerung und nicht zur Speicherung verwendet. Sie übertragen einen kleinen Zustandsnachweis in die Kette, z. B. einen Hash eines DID-Dokuments, eine Aktualisierung des Ausstellerregisters, einen Verweis auf den Berechtigungsstatus oder ein Schlüsselrotationsereignis, während die eigentlichen Identitätsdaten außerhalb der Kette bleiben.

Dadurch erhalten die Prüfer drei nützliche Eigenschaften:

Unveränderlichkeit: der verankerte Datensatz kann nicht stillschweigend geändert werden
Zeitstempel: Die Prüfer können sehen, wann der Zustand aufgezeichnet wurde.
Überprüfbarkeit: jeder kann überprüfen, ob die Off-Chain-Daten noch mit der On-Chain-Referenz übereinstimmen

Der Kompromiss ist die Dauerhaftigkeit. Wenn man die falschen Daten in die Kette einspeist, kann man sie nicht mehr sauber entfernen. Aus diesem Grund verankern ausgereifte DID-Systeme Hashes, Referenzen und Zustandsübergänge, nicht aber vollständige Anmeldeinformationen, Dokumente oder persönliche Daten.

Wenn Blockchain nicht erforderlich ist

Blockchain ist das falsche Werkzeug wenn es eine Vertrauensabhängigkeit nicht aufhebt. Wenn dieselbe Organisation den Emittenten, die Prüfstelle und die Anwendung kontrolliert, führt die Einbindung des DID-Status in die Kette in der Regel nur zu zusätzlichen Gebühren, Latenzzeiten und Betriebsstörungen.

Überspringen Sie Blockchain, wenn:

Das Vertrauen ist bereits in einer Organisation vorhanden
Emittent und Prüfer unterliegen derselben Kontrolle
DNS, HTTPS und signierte Anmeldedaten sind ausreichend
Audit-Protokolle erfüllen bereits die Compliance-Anforderung
Ketten-Metadaten würden ein Risiko für die Privatsphäre darstellen
Geringe Latenzzeit ist wichtiger als öffentliche Überprüfbarkeit

Deshalb ist tat:web für viele Identitätsströme in Unternehmen so gut funktioniert. Das DID-Modell wird beibehalten, aber es wird die bestehende Web-Infrastruktur genutzt, anstatt jede Aktualisierung durch eine Blockchain-Transaktion zu erzwingen.

Verwenden Sie Blockchain, wenn unabhängige Parteien einen gemeinsamen Zustand benötigen, den sie überprüfen können, ohne Ihrem Server zu vertrauen. Andernfalls sollten Sie es außerhalb der Blockchain halten. Mehr Dezentralisierung auf dem Papier bedeutet nicht automatisch eine bessere Identitätsarchitektur.

Erlaubt zk-L2 als dritter Pfad

Bei Systemen wie der digitalen Identitätsbörse der EU oder mobilen Führerscheinen (ISO 18013-5) wurde PKI vor allem deshalb gewählt, weil öffentliche L1/L2-Netze die wichtigsten Identitätsanforderungen nicht erfüllen: Datenschutz, Datensouveränität und regulatorische Kontrolle. Identitätsdaten können nicht öffentlich vervielfältigt werden, und die Behörden müssen streng kontrollieren, wo die Daten verarbeitet und gespeichert werden.

Neuere Architekturen bieten jedoch eine dritte Möglichkeit: zugelassene zk-L2-Systeme. Diese kombinieren:

Erlaubte Ausführung (wer den Status lesen/schreiben kann, wird kontrolliert)
Null-Wissen-Beweise (Zustandsübergänge können ohne Offenlegung der zugrunde liegenden Daten überprüft werden)
Öffentliche Verankerung (die Integrität wird über eine gemeinsame kryptografische Wurzel durchgesetzt)

Der Kerngedanke ist die Trennung der Belange auf der Ebene der Infrastruktur:

Privater Staat: Identitätsdaten, Berechtigungsnachweise und Transaktionslogik verbleiben in kontrollierten Umgebungen (z. B. pro Organisation oder Gerichtsbarkeit)
Gemeinsamer Staat: nur Korrektheitsnachweise veröffentlicht oder verankert werden
Verifizierung: Externe Parteien überprüfen Nachweise, nicht Rohdaten

Dadurch wird eine wesentliche Einschränkung öffentlicher Ketten vermieden: die Offenlegung von Daten. Gleichzeitig wird eine Einschränkung der reinen PKI vermieden: die Abhängigkeit von geschlossenen Vertrauenshierarchien ohne gemeinsame Überprüfbarkeit.

Eine weitere wichtige Eigenschaft ist Multi-Domain-Architektur. Verschiedene Akteure - Ministerien, Aufsichtsbehörden, Banken oder Regionen - können in getrennten Ausführungszonen mit ihren eigenen Compliance-Grenzen operieren, aber dennoch durch Nachweise zu einem gemeinsamen überprüfbaren Zustand beitragen.

Dadurch erweitert sich der Gestaltungsspielraum für Identitätssysteme. Anstatt zwischen einer zentralisierten PKI und einer öffentlichen Blockchain zu wählen, können neue Implementierungen Datenschutz, Compliance und gemeinsames Vertrauen in einem einzigen Modell kombinieren.

Vorteile von dezentraler Identität und DIDs

Ok, jetzt sollte klar sein, was DIDs anders machen als die Standard-KYC. Aber die praktischere Frage ist: Was ändert das eigentlich für mich? Gute Frage. Nach dem, was ich in realen Implementierungen gesehen habe, hängt die Auswirkung stark davon ab, auf welcher Seite man steht, daher lohnt es sich, sie aufzuschlüsseln.

Vorteile für Einzelpersonen

Für die Nutzer ist die größte Veränderung die Kontrolle über wann und wie die Identität geteilt wird.

Kein wiederholtes Onboarding: Ein einmal ausgestellter Ausweis kann dienstübergreifend wiederverwendet werden. Sie müssen nicht jedes Mal denselben Reisepass und dasselbe Selfie einreichen.
Selektive Offenlegung: Sie weisen nur das nach, was der Dienst wissen muss. “Über 18” anstelle Ihres vollständigen Geburtsdatums. “KYC bestanden” anstelle von Pass-Scans, Selfies und Adressdaten. “Kreditwürdigkeit innerhalb eines akzeptierten Bereichs” statt des genauen Ergebnisses oder der dahinter stehenden Finanzdaten.
Geringeres Risiko einer Verletzung: Ihre Daten werden nicht in jede Datenbank der Plattform kopiert. Weniger Kopien bedeuten weniger Angriffsflächen.
Mehr Datenschutz durch Design: Bei paarweisen DIDs sehen verschiedene Dienste unterschiedliche Kennungen. Die plattformübergreifende Verfolgung wird dadurch viel schwieriger.
Tragbarkeit: Ihre Identitätsartefakte leben mit Ihnen und sind nicht im System eines einzelnen Anbieters eingeschlossen.

In der Praxis bedeutet dies, dass die Identität nicht mehr etwas ist, das man ständig neu vorlegt, sondern etwas, das man bei Bedarf anwesend.

Vorteile für Organisationen

Für Unternehmen geht es dabei weniger um UX als vielmehr um Risiko- und Kostenstruktur.

Weniger sensible Daten müssen gespeichert werden: Sie verifizieren Ansprüche, anstatt rohe Identitätsdaten zu speichern. Das reduziert die Haftung, insbesondere im Rahmen von Vorschriften wie GDPR.
Wiederverwendbare KYC-/Compliance-Signale: Anstatt jedes Mal eine vollständige KYC durchzuführen, können Sie Bescheinigungen von vertrauenswürdigen Emittenten akzeptieren. Das verkürzt das Onboarding und senkt die Betriebskosten.
Schnellere Überprüfungsabläufe: Es ist nicht mehr nötig, auf externe APIs zu warten oder jede Interaktion manuell zu überprüfen. Die Verifizierung erfolgt lokal und deterministisch.
Plattformübergreifende Interoperabilität: In einem System ausgestellte Berechtigungsnachweise können in einem anderen System überprüft werden, solange die Vertrauensrahmen übereinstimmen.
Durchsetzung in der Kette, wenn nötig: Bei tokenisierten Systemen kann die Einhaltung der Vorschriften direkt in Smart Contracts über Signale wie soulbound tokens durchgesetzt werden.

Was sich operativ ändert, ist Folgendes: Sie hören auf, ein Datenverwalter zu sein, und werden zu einem Anspruchsprüfer.

Vorteile für Entwickler

Für Entwickler ist der Wert in wie die Identitätslogik aufgebaut ist.

Zustandslose Überprüfung: Sie brauchen keine Benutzeridentitätsdatenbank zu unterhalten oder sich auf Aussteller-APIs zur Laufzeit zu verlassen. Sie verifizieren Signaturen und Status lokal.
Klare Trennung der Anliegen: Ausstellung, Speicherung und Überprüfung sind voneinander entkoppelt. Das macht es einfacher, über Systeme nachzudenken und sie zu integrieren.
Zusammensetzbare Identitätsschicht: Berechtigungsnachweise können anwendungsübergreifend wiederverwendet werden, einschließlich dApps, APIs und Backend-Services.
Native fit für intelligente Verträge: Identitätssignale (z. B. Konformitätsstatus) können direkt von Verträgen genutzt werden, ohne dass Nutzerdaten offengelegt werden.
Standardbasierte Integration: Sie bauen auf W3C-Spezifikationen wie DID Core und Verifiable Credentials auf, nicht auf benutzerdefinierten Identitätsformaten.

Vom technischen Standpunkt aus betrachtet, findet eine Verlagerung von der “Verwaltung von Benutzern und Sitzungen” zu Überprüfung von Beweisen und Durchsetzung von Bedingungen.

Reduzieren Sie die KYC-Kosten mit den DID-Lösungen von Innowise

Anwendungsfälle aus der Praxis

Lassen wir einmal die Theorie beiseite und gehen wir das Ganze wie in einem echten System durch. Was bedeutet DID eigentlich sich fühlen wie in der Praxis? Wo hört es auf, ein Diagramm zu sein, und fängt an, etwas zu sein, das man verschiffen würde?

Sie werden feststellen, dass sich die Objekte ändern - Abschlusszeugnis, beruflicher Werdegang, KYC-Status - aber der Ablauf ändert sich kaum.

Ausbildung und Zeugnisse

Nehmen wir an, Sie haben gerade Ihren Abschluss gemacht und müssen einem zukünftigen Arbeitgeber Ihren Abschluss nachweisen. Der übliche Weg ist umständlich: Sie laden eine PDF-Datei hoch, fügen einen Scan an und warten vielleicht, bis jemand eine E-Mail an die Zulassungsstelle schickt. Es funktioniert, aber kaum. Der gesamte Prozess ist auf manuelles Vertrauen angewiesen.

Bei einer DID-basierten Bescheinigung stellt die Universität eine überprüfbare Bescheinigung aus, wenn Sie Ihren Abschluss machen. Sie befindet sich in Ihrer Brieftasche und ist mit einem Schlüssel unterzeichnet, der im DID-Dokument der Universität veröffentlicht ist.

Monate später bewerben Sie sich um eine Stelle. Der Arbeitgeber braucht die Universität nicht zu kontaktieren. Sie legen die Zeugnisse vor, und das System prüft sie:

Der DID der Universität
Der öffentliche Schlüssel in seinem DID-Dokument
Die Signatur des Berechtigungsscheins
Status des Verfalls oder der Aufhebung

Das ist das Schöne an diesem Modell: die Universität unterschreibt einmal, Sie verwenden den Nachweis wieder, und jeder Prüfer kann ihn unabhängig überprüfen.

Überprüfung von Beschäftigung und Arbeitskräften

Wie viel von einem Lebenslauf kann man tatsächlich glauben? Titel werden aufgeblasen. Daten werden unscharf. “Ein Team leiten” kann alles Mögliche bedeuten, von der Leitung von zehn Mitarbeitern bis zur Durchführung von Standups.

Jetzt drehen Sie das Modell um. Wenn Sie ein Unternehmen verlassen, wird Ihnen ein Zeugnis ausgestellt:

Ihre Rolle
Zeitspanne
Zertifizierungen oder interne Schulungen
Freigabestufe, falls zutreffend

Wenn Sie das nächste Mal gefragt werden: “Können Sie beweisen, dass Sie X getan haben”, erklären Sie nichts. Du präsentierst. Und nein, das bedeutet nicht, dass Sie jedes Mal Ihren gesamten beruflichen Werdegang offenlegen müssen. Mit dem richtigen Ausweisformat kann der Inhaber eine engere Behauptung nachweisen, z. B.:

“Mehr als 3 Jahre Erfahrung”.”
“Arbeitete in einem regulierten Umfeld.”

...ohne die gesamte Beschäftigungsgeschichte zu übermitteln. Das ist eine ganz andere Haltung als “Senden Sie uns Ihren vollständigen Lebenslauf und Ihre Referenzen”.”

Finanzdienstleistungen und KYC

Hier wird die wiederverwendbare Identität offensichtlich. Sie verifizieren sich einmal bei einem vertrauenswürdigen Anbieter: Reisepass geprüft, Sanktionsprüfung bestanden, Gerichtsbarkeit bestätigt. Der Anbieter stellt eine KYC-Bestätigung für Ihre Brieftasche aus.

Nächste Plattform? Sie legen die Anmeldedaten vor, anstatt die gleichen Dokumente erneut hochzuladen. Die Plattform prüft:

Vertrauen des Emittenten
Gültigkeit der Unterschrift
Status des Verfalls oder der Aufhebung

Einige Tokenisierungs-Teams verwenden auch Seelengebundene Spielsteine als On-Chain-KYC-Marker: Diese Adresse hat die erforderliche Prüfung bestanden. Die Identitätsdaten bleiben außerhalb der Kette; die Kette trägt nur das Berechtigungssignal.

Nützlich, aber nur, wenn die Markierung weit gefasst und widerrufbar ist und nicht zu einem dauerhaften Verlust der Privatsphäre führt.

Gesundheitswesen und Datenaustausch

Das Gesundheitswesen ist ein Bereich, in dem die DID-Architektur an die kurze Leine genommen werden muss. Nehmen wir an, eine Klinik stellt Ihnen eine Impfbescheinigung aus, ein Labor signiert Ihr Bluttestergebnis und Ihr Arzt stellt Ihnen eine Rezeptbescheinigung aus. Sie bewahren sie in Ihrer Brieftasche auf, anstatt jeden Datensatz in einem anderen Portal verschwinden zu lassen.

Dann wechseln Sie den Arzt. Warten Sie darauf, dass ein System mit einem anderen kommuniziert? Müssen Sie sich mit PDFs herumschlagen? Nein. Sie teilen dem neuen Anbieter die spezifische Bescheinigung mit, die dieser benötigt. Sie überprüfen den Aussteller, die Unterschrift und den Status.

Und nur um das klarzustellen: Nichts davon erfordert, dass medizinische Daten in die Kette aufgenommen werden. Die Kette ist für Identifikatoren, Schlüssel, vielleicht Statusregister. Die sensiblen Daten bleiben außerhalb der Kette. Wenn diese Grenze nicht respektiert wird, ist das Design kaputt.

Authentizität der Lieferkette und der Produkte

Lassen wir einmal die Menschen beiseite. Nehmen Sie ein Produkt in die Hand - sagen wir, eine Flasche Olivenöl. Hochwertiges Etikett, schöne Verpackung. Ist es echt? Anstatt sich auf die Marke zu verlassen, tippen Sie mit Ihrem Telefon auf einen NFC-Tag. Hinter diesem Etikett befindet sich eine DID, die mit der Produktcharge verknüpft ist.

Was Sie zurückbekommen, sind signierte Daten:

Der Bauernhof sagt, wo und wann er produziert wurde
Prozessor unterzeichnet Transformationsschritte
Logistik unterzeichnet eichpflichtige Überweisungen
Zertifizierer unterzeichnet Inspektion

Sie können das Produkt buchstäblich von der Quelle bis zum Regal verfolgen. Ist damit alles gelöst? Nein. Wenn die erste Dateneingabe falsch ist, bleibt der Fehler bei allen weiteren Eingaben erhalten. Aber zumindest wissen Sie jetzt wer jeden Schritt unterschrieben. Das ist ein großer Fortschritt gegenüber “Vertrauen Sie uns”.”

Regierung und digitale IDs

Die Regierung ist der Ort, an dem die DID-Identität die Krypto-Blase verlässt. Ein wichtiger Bezugspunkt ist die EU-Geldbörse für digitale Identitäten im Rahmen von eIDAS 2.0, einer groß angelegten Initiative, die darauf abzielt, Geldbörsen für Bürger, Einwohner und Unternehmen in allen Mitgliedstaaten bereitzustellen.

Aber die breitere Landschaft ist noch vielfältiger. Einige der größten und ausgereiftesten digitalen Identitätssysteme weltweit sind nicht streng DID-basiert, folgen aber ähnlichen Mustern in Bezug auf wiederverwendbare Ausweise und vom Inhaber kontrollierte Daten:

Indiens Aadhaar-System, die mehr als eine Milliarde Nutzer abdeckt, kombiniert mit DigiLocker und e-KYC-Flows
Singapurs Singpass, ein hochintegriertes nationales Identitätssystem mit API-basierter Überprüfung und zustimmungsgesteuertem Datenaustausch
Mobile US-Führerscheine (mDL) nach ISO 18013-5, das bereits in mehreren Staaten eingesetzt wird und in mobile Geldbörsen integriert ist
Staatlich geführte Ausweissysteme wie GOV.UK One Login oder das OrgBook von British Columbia

Diese Systeme haben alle den gleichen Wandel zu verzeichnen: weg von zentralisierten Identitätsdatensätzen hin zu wiederverwendbaren, vom Benutzer vorgelegten Nachweisen. Gleichzeitig ist es wichtig, die Vertrauensmodelle zu trennen. Systeme wie eIDAS stützen sich auf föderierte PKI und Vertrauensdienstlisten, während DID-basierte Systeme auf kryptografischen Identifikatoren und überprüfbaren Berechtigungsnachweisen basieren. In der Praxis existieren diese Modelle oft nebeneinander, anstatt sich gegenseitig zu ersetzen.

Normen und Governance

Bisher hat alles innerhalb eines einzigen Systems gut funktioniert. Aber was passiert, wenn Berechtigungsnachweise Systemgrenzen überschreiten? Dann wird es schwierig. Sie brauchen gemeinsame Standards, damit die Daten überall Sinn machen, und Sie brauchen eine Governance, damit die Prüfer wissen, welchen Ausstellern sie vertrauen können. Hier sind die wichtigsten Standards und Governance-Ebenen.

W3C DID Core-Spezifikation

DID-Syntax (did:methode:id), DID-Dokumente, Verifikationsbeziehungen, Auflösungsmodell

DID-Dokument mit verificationMethod, Authentifizierung, assertionMethod, Dienst-Endpunkte

stellt sicher, dass jeder Prüfer eine DID auflösen kann und versteht, welche Schlüssel für welche Operationen gültig sind

Datenmodell für überprüfbare Berechtigungsnachweise

Struktur der Berechtigungsnachweise, Rollen von Ausstellern, Inhabern und Prüfern, Nachweisformate, Präsentationsmodell

JSON-LD- oder JWT-Berechtigungsnachweise, selektive Offenlegung, Austausch von Präsentationen

Ermöglicht die Übertragbarkeit von Berechtigungsnachweisen über verschiedene Systeme hinweg und deren Überprüfung ohne Beteiligung des Ausstellers

DIF (Dezentralisierte Identitätsstiftung)

Protokolle, Interoperabilitätsspezifikationen, Kommunikation zwischen Wallet und Agent, Austausch von Präsentationen

DIDComm-Nachrichtenübermittlung, Präsentationsaustausch, Brieftasche-zu-Brieftasche- oder Brieftasche-zu-Dienst-Flüsse

Verhindert eine Fragmentierung, indem verschiedene Geldbörsen und Verifizierer tatsächlich zusammenarbeiten

Rahmen des Vertrauens

Akkreditierung von Ausstellern, Berechtigungsschemata, Sicherheitsstufen, Governance-Regeln

Für eine Plattform zugelassene KYC-Anbieter, Schemadefinitionen für “verifizierter Anleger” oder “lizenzierte Einrichtung”

Legt fest, welche Nachweise akzeptabel sind und unter welchen Bedingungen man sich auf sie verlassen kann

Normen machen Ausweise interoperabel. Governance macht sie akzeptabel. Ohne Standards lässt sich nichts parsen. Ohne Governance ist nichts vertrauenswürdig. Echte Systeme funktionieren nur, wenn beide Ebenen gemeinsam definiert sind.

Beschleunigung der Überprüfung ohne externe Abhängigkeiten

Sicherheit und Einschränkungen

Normen sagen Ihnen, wie sich ein DID-System verhalten sollte. Die Produktion sagt Ihnen, wo es unübersichtlich wird. Heute gehen die meisten Risiken nicht von der DID-Syntax oder den Signaturalgorithmen selbst aus. Sie betreffen Brieftaschen, Schlüsselwiederherstellung, Widerruf, Interoperabilität und die Frage, ob genügend Emittenten und Prüfer sich tatsächlich darauf einigen, das gleiche Vertrauensmodell zu verwenden.

Sicherheit von Brieftasche und Schlüssel

In DID-Systemen hängt die Identität von der Schlüsselkontrolle ab. Das ist leistungsfähig, aber unversöhnlich. Wenn ein Benutzer den Schlüssel verliert, ist die Wiederherstellung nicht automatisch. Gelangt ein Angreifer in den Besitz des Schlüssels, kann er sich als dessen Inhaber ausgeben. Aus diesem Grund verlassen sich seriöse Implementierungen nur selten auf eine Rohdatenphrase allein. Sie benötigen in der Regel MPC, soziale Wiederherstellung, Hardware-gestützte Schlüssel oder ein hybrides Verwahrungsmodell.

Entzug und Status der Bescheinigung

Zeugnisse altern. KYC läuft ab, Mitarbeiter gehen, Lizenzen werden ausgesetzt. Die Überprüfung kann also nicht bei der Frage “Ist die Unterschrift gültig?” stehen bleiben. Die Prüfstelle prüft den Status des Ausweises zum Zeitpunkt der Verwendung. Das bedeutet in der Regel Statuslisten, Sperrverzeichnisse oder kurzlebige Ausweisdokumente. Wird dieser Teil vernachlässigt, sehen alte Berechtigungsnachweise weiterhin gültig aus.

Herausforderungen der Interoperabilität

Standards sind hilfreich, aber sie machen nicht auf magische Weise jede Wallet, jeden Emittenten und jeden Verifier kompatibel. Ein Stack verwendet vielleicht JSON-LD-Anmeldeinformationen, ein anderer bevorzugt vielleicht JWT. DID-Methoden. Die Darstellungsprotokolle unterscheiden sich. Ja, das Ökosystem bewegt sich in Richtung Interoperabilität, aber reale Projekte benötigen immer noch Integrationsarbeit und strenge Profilentscheidungen.

Hindernisse für die Annahme

Der schwierigste Teil ist die Koordination. Ein DID-System braucht Emittenten, denen die Menschen vertrauen, Prüfstellen, die bereit sind, Ausweise zu akzeptieren, Nutzer, die in der Lage sind, Wallets zu verwalten, und Governance-Regeln, die jeder versteht. Solange diese Teile nicht aufeinander abgestimmt sind, erfolgt die Einführung nur punktuell: reguliertes Finanzwesen, Tokenisierung, Mitarbeiterausweise, staatliche Ausweise und geschlossene Ökosysteme zuerst.

Post-Quantum-Risiko und Krypto-Agilität

Die meisten DID-Systeme basieren heute auf der Kryptographie mit elliptischen Kurven: Ed25519, secp256k1, oder P-256. Diese Verfahren sind weit verbreitet, aber sie sind nicht post-quantum-sicher. Ein hinreichend leistungsfähiger Quantencomputer könnte sie mit dem Shor-Algorithmus brechen, was die Fälschung von Unterschriften zu einem echten langfristigen Risiko macht.

Das ist wichtig, weil Identitätsnachweise oft jahrelang gültig sind. Diplome, Lizenzen und juristische Bescheinigungen, die heute ausgestellt werden, müssen unter Umständen auch dann noch überprüft werden, wenn die ihnen zugrunde liegende Kryptographie längst überholt ist.

Die Standards bewegen sich bereits in diese Richtung. Das NIST hat Post-Quantum-Signaturverfahren wie ML-DSA (Dilithium) und SLH-DSA (SPHINCS+) fertiggestellt, während das DID/VC-Ökosystem hybride Signaturen und Krypto-Agilität erforscht.

DID-Systeme sollten vom ersten Tag an mehrere Überprüfungsmethoden, neue Signatursuiten und klare Schlüsselrotationspfade unterstützen. Post-Quantum-Signaturen sind viel größer als Ed25519- oder ECDSA-Signaturen, was sich auf QR-Präsentationen, Register und On-Chain-Statusmechanismen auswirkt. Für langlebige Behörden- und Unternehmensidentitäten ist die Krypto-Agilität jedoch ein Muss.

Wie Organisationen dezentralisierte Identität implementieren

Der häufigste Fehler besteht darin, DID als etwas zu betrachten, das man zu einem bestehenden Identitätsstapel “hinzufügt”. In der Praxis geht es darum, wie man Vertrauen, Datenfluss und Verantwortung modelliert. Die technischen Aspekte sind selten der schwierigste Teil. Die meisten Projekte sind erfolgreich oder scheitern an der Koordination, Governance und Integration.

Verlagerung von der Datenspeicherung zur Überprüfung von Berechtigungsnachweisen

Ermitteln Sie zunächst, wo Sie Identitätsdaten speichern, um sie später zu überprüfen: KYC-Status, Alter, Beschäftigung, Lizenzen, Akkreditierung und Zugangsrechte. Ziel ist es, weniger Rohdaten zu speichern und mehr signierte Angaben zu verifizieren. Das reduziert die Haftung, vereinfacht die Einhaltung von Vorschriften und macht die Identität systemübergreifend übertragbar.

Definieren Sie Vertrauensbeziehungen und Berechtigungsschemata

Bevor Sie Werkzeuge auswählen, sollten Sie das Vertrauensmodell konkret definieren. In realen Projekten führt das in der Regel zu:

Ein Vertrauensrahmen-Dokument (wer kann was unter welchen Bedingungen ausstellen)
Onboarding-Regeln und SLAs für Emittenten
Berechtigungsschemata (JSON-LD oder JWT-basiert)
Rechtliche Überprüfung und Überprüfung der Einhaltung von Vorschriften für jede Art von Berechtigungsnachweis

Andernfalls erhalten Sie Ausweise, die zwar korrekt verifiziert, aber von den Überprüfern nicht akzeptiert werden.

Normen und DID-Methoden auswählen

Wählen Sie nun den technischen Stack. Wählen Sie die DID-Methode, das Berechtigungsformat, den Wallet-Flow und das Widerrufsmodell. tat:web in der Regel für Unternehmen und SaaS-Ströme geeignet. tat:ethr passt zur Durchsetzung von Smart Contracts und zur On-Chain-Identität. hat:Schlüssel passt zu kurzlebigen oder lokalen Identifikatoren.

Entscheiden Sie sich nicht für die “dezentralste” Option. Wählen Sie die Option, die Ihrer Vertrauensgrenze entspricht.

Beginnen Sie mit einem Pilotprojekt

Beginnen Sie nicht mit “Identität für alles”. Beginnen Sie mit einem Fluss, bei dem der Schmerz klar ist. Gute Piloten sind:

Wiederverwendbare KYC für ein einzelnes Produkt
Zeugnisse von Auftragnehmern oder Arbeitskräften
Wallet-basierte Zugangskontrolle
Anlegerverifizierung für tokenisierte Vermögenswerte

Enger Anwendungsbereich: ein Berechtigungstyp, ein oder zwei Aussteller, ein Überprüfungsablauf, klare Widerrufsregeln. Vermeiden Sie den Beginn mit:

Stark regulierte Mitarbeiteridentität in großen Organisationen
Grenzüberschreitende Identität ohne einen vereinbarten Vertrauensrahmen
Vollständige Identitätsplattformen anstelle eines einzigen Anwendungsfalls

Beweisen Sie den Fluss von Ende zu Ende und erweitern Sie dann.

Widerrufsmodelle und Abwägungen

Sobald man von einem Pilotprojekt zur Produktion übergeht, ist die Ausstellung von Berechtigungsnachweisen nur noch die Hälfte des Problems. Die schwierigere Frage ist, was passiert, wenn ein Berechtigungsnachweis nicht mehr vertrauenswürdig ist: eine KYC-Prüfung läuft ab, ein Mitarbeiter verlässt das Unternehmen, eine Lizenz wird ausgesetzt oder eine Brieftasche wird kompromittiert.

Es gibt keinen einzigen Standardansatz, und jedes Modell bringt Kompromisse mit sich:

Statuslisten (z. B. W3C Bitstring Status List): weit verbreitet und kosteneffizient, erfordern aber regelmäßige Überprüfungen und können Metadaten preisgeben
On-Chain-Register: schnelles Nachschlagen und gemeinsamer Status, aber Kosten und öffentliche Sichtbarkeit
Kryptographische Akkumulatoren: Wahrung der Privatsphäre, aber rechenintensiv und schwieriger auf mobilen Geräten einzusetzen
Kurzlebige Berechtigungsnachweise: einen Widerruf gänzlich vermeiden, aber eine häufige Neuausstellung und einen Online-Zugang des Ausstellers erfordern

Verschiedene Ökosysteme verfolgen unterschiedliche Ansätze. So beruhen beispielsweise mobile Führerscheine nach ISO 18013-5 eher auf der Validierung des Ausstellers und auf Vertrauenslisten als auf einem Widerruf nach W3C-Vorbild. Ohne eine klare Widerrufsstrategie bricht das Modell der “wiederverwendbaren Berechtigungsnachweise” zusammen. Ein kompromittierter Berechtigungsnachweis kann weiterhin vorgelegt werden, wenn sein Status nicht aktiv überprüft wird.

So sieht eine typische Umsetzung aus

Ein typisches DID/VC-Projekt verläuft in Phasen. Ein Pilotprojekt dauert in der Regel 3-4 Monate und validiert einen Anwendungsfall von Ende zu Ende, typischerweise im Bereich von $150K–$300K, je nach Umfang. Ein Produktionsrollout dauert 9-12 Monate und erweitert sich auf mehrere Aussteller, Prüfer und Berechtigungstypen, in der Regel von $800K bis $2M+, abhängig von der Komplexität der Integration und den Anforderungen an die Einhaltung der Vorschriften.

Zu einem typischen Team gehören:

Architekt der Identität
Kryptographie / PKI-Ingenieur
Wallet- oder Mobile-Entwickler
Backend-/Integrationsingenieur
Leitung Compliance oder Recht
Entwickler von intelligenten Verträgen (wenn On-Chain-Komponenten verwendet werden)

In der Praxis liegt die Komplexität selten in der Kryptographie. Sie liegt in der Integration, der Verwaltung und der Benutzerfreundlichkeit.

Ersetzen Sie Dokumentenprüfungen durch kryptografische Nachweise

Die Zukunft der dezentralen Identität

Um dies abzuschließen, lassen Sie uns ein wenig herauszoomen. Die DID-basierte Identität ist kein fertiger Stack. Er befindet sich noch in der Entwicklung, vor allem in Bezug auf Nachweissysteme, Brieftascheninfrastruktur, Interoperabilitätsebenen und die Integration von Vorschriften. Aus dem, was ich in realen Implementierungen sehe, werden einige Richtungen deutlich.

Wiederverwendbare Identität über Plattformen hinweg

Eine wiederverwendbare Identität ist das offensichtliche Endziel, aber der Engpass ist nicht die Überprüfung der Unterschrift. Dieser Teil funktioniert bereits. Der schwierigere Teil ist das Vertrauen des Ausstellers, die Schemata der Berechtigungsnachweise und die Akzeptanzregeln.

Künftig sollte ein in einem regulierten Umfeld ausgestellter KYC-Nachweis über Börsen, Tokenisierungsplattformen, Kreditprodukte und konforme DeFi-Schnittstellen hinweg wiederverwendbar sein, vorausgesetzt, die DID des Ausstellers ist auflösbar, das Schema wird verstanden und die Prüfstelle akzeptiert den Aussteller in ihrem Vertrauensrahmen. Darin liegt die eigentliche Arbeit: nicht zu beweisen, dass eine Signatur gültig ist, sondern zu vereinbaren, was die signierte Forderung tatsächlich bedeutet.

Null-Wissen-Beweise für selektive Offenlegung

Heute weisen viele Systeme noch Eigenschaften auf. Die Zukunft ist der Nachweis von Bedingungen. Anstatt Ihr Geburtsdatum anzugeben, weisen Sie nach, dass Sie über 18 Jahre alt sind. Anstatt die vollständigen KYC-Daten offenzulegen, beweisen Sie, dass Sie eine bestimmte Compliance-Richtlinie erfüllt haben. Anstatt ein Rechtsprechungsfeld freizugeben, weisen Sie die Berechtigung für eine Transaktion nach.

Technisch gesehen deutet das auf BBS+-Signaturen für die selektive Offenlegung und zk-SNARKs oder zk-STARKs für Prädikatsnachweise hin. Der Verifizierer prüft den Beweis anhand der vom Aussteller kontrollierten öffentlichen Schlüssel, während die zugrunde liegenden persönlichen Daten verborgen bleiben. Damit ändert sich das Datenschutzmodell von “weniger Daten weitergeben” zu “gar keine Daten weitergeben, wenn ein Beweis ausreicht”.”

Interoperabilität und plattformübergreifende Identität

Die Interoperabilität wird darüber entscheiden, ob die dezentralisierte Identität fragmentiert bleibt oder zu einer brauchbaren Infrastruktur wird.

Die Schwachstellen sind nach wie vor bekannt: JSON-LD vs. JWT-Berechtigungsnachweise, unterschiedliche DID-Methoden, unterschiedliche Brieftaschenprotokolle, unterschiedliche Präsentationsabläufe. Aus diesem Grund definieren Produktionssysteme zunehmend strenge Profile: zugelassene Berechtigungsformate, unterstützte DID-Methoden, vertrauenswürdige Aussteller und akzeptierte Präsentationsprotokolle.

Im Laufe der Zeit erwarte ich eine stärkere Konvergenz in Bezug auf den Fluss von Brieftaschen zu Überprüfern, den Austausch von Präsentationen und Vertrauensregistern. Ohne dies wird jedes DID-Projekt zu einer weiteren Identitätsinsel. Damit können Berechtigungsnachweise plattformübergreifend genutzt werden, ohne dass jedes Mal eine individuelle Integration erforderlich ist.

Regulatorische Entwicklungen

Durch die Regulierung wird die dezentrale Identität von einer technischen Option zu einer öffentlichen Infrastruktur.

In der EU sind eIDAS 2.0 und die EU Digital Identity Wallet das große Signal. Die Mitgliedstaaten sind verpflichtet, eine Wallet-Infrastruktur mit Berechtigungsnachweisen für Identitätsattribute, Lizenzen, Qualifikationen und Anwendungsfälle im öffentlichen und privaten Sektor bereitzustellen. Damit wird eine regulierte Ausweisschicht in ganz Europa geschaffen.

In den USA aktualisiert das National Institute of Standards and Technology die Richtlinien zur digitalen Identität (z. B. NIST 800-63), um kryptografische Berechtigungsnachweise, Zuverlässigkeitsstufen und datenschutzfreundliche Verifizierung zu berücksichtigen. Die USA werden wahrscheinlich ein eher marktorientiertes Modell beibehalten, während die EU einen koordinierten Rahmen für Brieftaschen vorantreibt.

Wohin soll das führen? In Richtung weniger Dokumenten-Uploads, mehr wiederverwendbare Ausweise, mehr lokale kryptografische Überprüfungen und eine selektivere Offenlegung. Die Gewinner werden nicht die Systeme sein, die die meisten Identitätsdaten speichern. Sie werden diejenigen sein, die die richtige Behauptung mit dem geringsten Risiko überprüfen können.

FAQ

Was ist ein dezentraler Identifikator (DID)?

Ein dezentraler Identifikator ist ein eindeutiger, auflösbarer Identifikator, der auf ein DID-Dokument verweist, das öffentliche Schlüssel und Überprüfungsmethoden enthält. Er ermöglicht den Nachweis von Identität oder Kontrolle, ohne sich auf eine zentrale Behörde zu verlassen. In der Praxis werden Datenbankabfragen durch kryptografische Überprüfungen ersetzt.

Wie funktionieren dezentralisierte Identifikatoren?

Ein DID wird in ein DID-Dokument mit öffentlichen Schlüsseln aufgelöst. Ein Aussteller signiert einen Berechtigungsnachweis, ein Inhaber speichert ihn, und ein Prüfer überprüft die Signatur und den Status anhand der DID des Ausstellers. Es ist kein direkter Aufruf des Ausstellers erforderlich. Dies macht die Überprüfung portabel und unabhängig von einem einzelnen System.

Was ist der Unterschied zwischen dezentraler Identität und DID?

Unter dezentraler Identität versteht man das Gesamtmodell der Ausstellung und Überprüfung von Ansprüchen ohne zentrale Speicherung. Eine DID ist nur eine Komponente dieses Modells. Sie dient als Identifizierungsschicht für die Auflösung von Schlüsseln und die Überprüfung von Signaturen. Ohne DIDs gäbe es im System keine einheitliche Möglichkeit, Verifizierungsmaterial zu finden und ihm zu vertrauen.

Werden dezentralisierte Identifikatoren in einer Blockchain gespeichert?

Nicht unbedingt. Einige DID-Methoden verwenden Blockchains zur Auflösung oder Verankerung, aber viele, wie tat:web, basieren auf einer Standard-Web-Infrastruktur. Die DID selbst ist eine Referenz, kein Datensatz. Was in der Kette gespeichert werden kann, sind Schlüssel, Hashes oder Statusreferenzen, keine Identitätsdaten.

Wofür werden dezentrale Identifikatoren verwendet?

Sie werden verwendet, um Identitäten mit kryptografischen Schlüsseln zu verknüpfen, überprüfbare Berechtigungsnachweise zu ermöglichen, wiederverwendbare KYC, die Überprüfung von Arbeitskräften, digitale IDs und die Zugangskontrolle sowohl in web- als auch in blockchainbasierten Systemen zu unterstützen. Ihre Aufgabe besteht darin, die Identitätsüberprüfung systemübergreifend zu ermöglichen.

Wie erstellt man einen dezentralen Identifikator (DID)?

Sie generieren ein Schlüsselpaar und erstellen eine DID nach einer gewählten Methode. Dann veröffentlichen oder registrieren Sie es, damit es in ein DID-Dokument aufgelöst werden kann. Der genaue Vorgang hängt von der DID-Methode ab (z. B. web-, blockchain- oder schlüsselbasiert). Die Methode bestimmt, wie die DID verankert, aktualisiert und aufgelöst wird.

Andrew Nalichaev

Blockchain-Experte und DeFi-Analyst

Andrew übersetzt dezentralisierte Konzepte in sichere, funktionale Finanztools. Er navigiert durch die unbeständige DeFi-Landschaft, um skalierbare Blockchain-Infrastrukturen aufzubauen, die einen realen Nutzen bieten und über die Schlagworte hinausgehen, um technischen Wert zu liefern.

Mehr erfahren

Inhaltsübersicht

Kontakt aufnehmen

Anruf vereinbaren oder füllen Sie das Formular aus. Wir kontaktieren Sie, sobald wir Ihre Anfrage bearbeitet haben.

Name

Unternehmen

E-Mail

Telefon

Nachricht

Sprachnachricht senden

Datei beifügen

Datei hochladen

Sie können 1 Datei mit bis zu 2 MB anhängen. Gültige Dateiformate: pdf, jpg, jpeg, png.

Mit dem Klicken auf Senden erklären Sie sich damit einverstanden, dass Innowise Ihre personenbezogenen Daten gemäß unserer Datenschutzerklärung verarbeitet, um Ihnen relevante Informationen bereitzustellen. Mit Angabe Ihrer Telefonnummer stimmen Sie zu, dass wir Sie per Sprachanruf, SMS oder Messaging-Apps kontaktieren. Es können Gebühren für Anrufe, Nachrichten und Datenübertragung anfallen.

Sie können uns auch kontaktieren
bis hin zu contact@innowise.com

Wie geht es weiter?

Sobald wir Ihre Anfrage erhalten und geprüft haben, melden wir uns bei Ihnen, klären erste Fragen und unterzeichnen bei Bedarf ein NDA, um die Vertraulichkeit zu gewährleisten.

Nach genauer Prüfung Ihrer Anforderungen, Bedürfnisse und Erwartungen wird unser Team einen Projektvorschlag mit Angaben zu Arbeitsumfang, Teamgröße, Zeitaufwand und Kosten erstellen.

Wir vereinbaren einen Termin, um das Angebot gemeinsam zu besprechen und alle Details festzulegen.

Abschließend unterzeichnen wir den Vertrag und starten umgehend mit der Umsetzung Ihres Projekts.

Fallstudien

Blog

How to move USDT from Tron to EVM without getting trapped by liquidity.

Wie man USDT von Tron zu EVM verschiebt, ohne in die Liquiditätsfalle zu geraten

Finden Sie heraus, welche Möglichkeiten es gibt, USDT von Tron zu EVM-Netzwerken zu transferieren, und was jede einzelne davon kostet.

Andrew Nalichaev

Apr 2, 2026

Blog

Why DevOps is becoming the new standard for digital banking.

Warum DevOps für digitales Banking unverzichtbar wird

Müssen Sie immer noch auf Anrufe und Checklisten zurückgreifen? Hier ist der Grund, warum die Banken weitergemacht haben.

Igor Aristov

26. Feb. 2026

Blog

Crypto exchange development cost in 2026: CEX vs. DEX breakdown.

Entwicklungskosten für Krypto-Börsen im Jahr 2026: Aufschlüsselung CEX vs. DEX

Entwicklungskosten für Kryptobörsen im Jahr 2026 erklärt. Vergleichen Sie CEX vs. DEX, Preisfaktoren und intelligente Wege zum Start.

Andrew Nalichaev

13. Januar 2026

Blog

Top Blockchain development companies of 2025.

Top Blockchain-Entwicklungsunternehmen von 2025

Entdecken Sie führende Blockchain-Innovatoren und erfahren Sie, wie Sie den perfekten Partner für Ihr Projekt finden.

Andrew Nalichaev

26. Sept 2025

Blog

Cryptocurrency wallet app development considerations.

Überlegungen zur Entwicklung von Cryptocurrency-Wallet-Apps

Erfahren Sie, wie Sie sichere, skalierbare Blockchain-Wallets mit Multi-Coin-Unterstützung, KYC und nahtloser UX erstellen.

Andrew Nalichaev

17. Juni 2025

Blog

How to get listed on a cryptocurrency exchange?.

Wie kann man an einer Kryptowährungsbörse gelistet werden?

Erforschen Sie den gesamten Prozess der Börsennotierung Ihrer Kryptowährungen, von den Börsenanforderungen bis hin zu Dokumenten, Integrationen und Marketing.

Andrew Nalichaev

6. Juni 2025

Blog

Top Layer 2 blockchains: find the right fit for your project.

Top Layer 2 Blockchains: Finden Sie die richtige Lösung für Ihr Projekt

Welche Layer-2-Lösungen sind führend? Vergleichen Sie Geschwindigkeit, Kosten und Funktionen der wichtigsten Blockchain-Optionen.

Alex Kalinovski

9, Mai 2025

Blog

Coding the future: 14 software development trends you can’t ignore in 2025.

Kodierung der Zukunft: 14 Trends in der Softwareentwicklung, die Sie 2025 nicht ignorieren können

Entdecken Sie die neue Welle von Softwareentwicklungstrends und erfahren Sie, wie sie den ROI verbessern und das Unternehmenswachstum fördern können.

Ivan Shatukha

21. Apr 2025

Blog

Best blockchain programming languages: ultimate overview.

Beste Blockchain-Programmiersprachen: ultimativer Überblick

Vergleichen Sie die besten Blockchain-Sprachen nach Leistung, Sicherheit und Benutzerfreundlichkeit und wählen Sie die beste Sprache für Ihre Blockchain-Projekte.

Andrew Nalichaev

7. Februar 2025

Blog

What is so smart about smart contract platforms and why build a custom one?.

Was ist das Clevere an intelligenten Vertragsplattformen und weshalb sollte man eine individuelle Plattform aufbauen?

Erfahren Sie, was Smart-Contract-Plattformen sind, wie sie dApps ausführen und welche Ökosysteme sie betreiben.

Andrew Nalichaev

Jan 25, 2025

Blog

Blockchain in healthcare: practical applications, benefits, and examples.

Blockchain im Gesundheitswesen: Leitfaden zu Anwendungen, Vorteilen und Beispielen

Das Gesundheitswesen trifft auf Blockchain: Wie dezentralisierte Technologie die Interoperabilität verbessert und die Privatsphäre der Patienten schützt.

Aleh Yafimau

24. Jan 2025

Blog