Souveräne Identitätsschicht in der Blockchain

Authentifizierung beantwortet, wer einen Schlüssel in diesem Moment kontrolliert. Identität schafft Kontinuität: wie eine Partei Schlüssel rotiert, ihre Handlungsbefugnis nachweist, einen Nachweis erhält, einen Agenten begrenzt und sich nach Geräteverlust erholt. Eine souveräne Identitätsschicht koordiniert diese Funktionen, ohne einen Plattform-Login zur einzigen Vertrauenswurzel zu machen.

Das Wort souverän bedeutet nicht standardmäßig anonym oder von Richtlinien ausgenommen. Es bedeutet, dass das Subjekt oder ein ausdrücklich autorisierter Controller eine sinnvolle kryptografische Kontrolle hat. Eine gute Implementierung kann Privatpersonen, regulierte Organisationen, Validatoren, IoT-Geräte, Smart Contracts oder KI-Agenten unterstützen, wobei jeweils eine passende Nachweis- und Offenlegungsrichtlinie verwendet wird.

In einer Architekturprüfung lassen sich vier Schichten leicht trennen. Der Identifikator benennt das Subjekt. Das DID-Dokument veröffentlicht Verifikationsmethoden und Service-Endpunkte. Nachweise enthalten signierte Aussagen von Ausstellern. Eine Wallet- oder Agent-Laufzeit hält private Schlüssel und bittet vor einer Präsentation um Zustimmung. Werden diese Aufgaben vermischt, entstehen fragile Systeme und eine breite Datenoffenlegung.

Es gibt auch einen operativen Test. Eine Identitätsschicht benötigt dokumentierte Antworten für kompromittierte Schlüssel, Widerruf, Resolver-Verfügbarkeit, Vertrauen in Aussteller, Korrelationsrisiken, Speicherung personenbezogener Daten und Wallet-Migration. Eine Blockchain kann öffentlichen Zustand manipulationssicher machen; sie kann allein nicht entscheiden, ob einem Aussteller vertraut werden sollte oder ob eine offengelegte Aussage angemessen ist.

W3C published Decentralized Identifiers v1.0 am 19. Juli 2022 als offiziellen Webstandard. Der Standard definiert eine DID als URI im Format did:method:method-specific-id, ein gemeinsames Datenmodell für DID-Dokumente sowie abstrakte Schnittstellen für Auflösung und Dereferenzierung. Das zugrunde liegende Register und die Betriebsregeln überlässt er bewusst jeder DID-Methode.

Ein DID-Dokument hat eine erforderliche Eigenschaft der obersten Ebene, id. Häufige optionale Eigenschaften sind controller, verificationMethod, Authentifizierungs- und Assertion-Beziehungen, Schlüsselvereinbarung, delegierte Fähigkeiten und Service-Endpunkte. Private Schlüssel gehören nicht in das DID-Dokument.

Die Empfehlung von 2022 verzeichnete 103 experimentelle DID-Methodenspezifikationen, 32 experimentelle Treiberimplementierungen und 46 Implementierungen in ihrer Konformitätssuite. Diese Zahlen aus the W3C specification sind ein nützliches historisches Signal: Eine Standardsyntax verbessert die Interoperabilität, beseitigt aber nicht die Entwurfsentscheidungen von Hunderten Methoden.

„Dezentrale Identifikatoren (DIDs) sind entscheidend, um ein sichereres Web und die Art selbstbestimmter Verbrauchererlebnisse zu gewährleisten, die wir bei Avast ermöglichen.“

Die Auflösung verbindet einen Identifikator mit nutzbarem Verifikationsmaterial. Ein Resolver wendet die Leseregeln der Methode an und gibt ein DID-Dokument plus Metadaten zurück. Daher ist die Methodenwahl wichtig: Ein did:web-Identifikator hängt von Webhosting und Domainkontrolle ab, eine Ledger-verankerte Methode von Verfügbarkeit und Gebührenmodell des Netzwerks, und eine schlüsselabgeleitete Methode hat andere Kompromisse bei Aktualisierung und Wiederherstellung.

Für eine vertiefende Einführung mit Autheo-Bezug siehe die decentralized identifier FAQ und die W3C DID Core compliance FAQ. Beide sollten als Roadmap-Kontext für TheoID gelesen werden, nicht als Behauptung, dass TheoID heute verfügbar ist.

Ethereum verfügt über ein reiches Identitätsökosystem, weil Konten, Signaturen, Verträge und öffentlicher Zustand kombinierbar sind. Es schreibt keine netzwerkweite Identitätsschicht vor. Stattdessen kombinieren Entwickler je nach Problem Adresskontrolle, Wallet-Signaturen, Vertragskonten, Namensgebung, DID-Methoden, Bibliotheken für Nachweise und Anwendungsrichtlinien.

ENS ist die bekannteste Namensschicht dieses Ökosystems. Seine documentation beschreibt die Entwicklung von Anwendungen mit dezentraler souveräner Identität und behandelt Adressauflösung, Textdatensätze, Avatare, primäre Namen, Register, Resolver und kettenübergreifende Resolver. Ein ENS-Name kann ein menschenlesbarer Handle und eine Auffindungsfläche sein, doch ein Name allein ist kein vollständiges System für den Nachweislebenszyklus.

ERC-1056, also known as Ethereum Lightweight Identity spezifiziert ein gemeinsames Ethereum-DID-Register für die Verwaltung von Schlüsseln und Attributen. Der Entwurf behandelt Ethereum-Konten als Identitäten, unterstützt unbegrenzt viele Delegierte und Attribute und ermöglicht Schlüsselrotation, während der primäre Identifikator stabil bleibt. Die Identitätserstellung erfordert keine separate Registrierungstransaktion, weil das Konto selbst der Ausgangspunkt ist.

Diese Flexibilität ist Ethereums Stärke und zugleich der Integrationsaufwand. Ein Produkt kann ENS für Auffindbarkeit, Sign-In with Ethereum für Sitzungs-Authentifizierung, ERC-1056 oder did:ethr-Werkzeuge für DID-Dokumente und einen separaten Stack für überprüfbare Nachweise verwenden. Jede Komponente kann ausgezeichnet sein, doch das Team muss Grenzen für Interoperabilität, Transaktionskosten, Datenschutz, Wiederherstellung und Support definieren.

Sehen Sie sich den vorhandenen Autheo and Ethereum comparison für eine breitere Infrastrukturperspektive an. Die relevante Erkenntnis ist nicht, dass Ethereum keine Identitätsinnovation bietet. Ethereum unterstützt mehrere Identitätsansätze, während zweckgebundene Systeme andere Kompromisse bei Registerdesign und Datenschutz für Nachweise eingehen.

Hyperledger Indy wählte die entgegengesetzte Architektur: ein tokenloses, öffentliches, berechtigtes Ledger, das speziell für datenschutzschonende überprüfbare Nachweise entwickelt wurde. Der Jahresbericht 2024 beschreibt das Projekt als stabil und robust, nennt bestehende Anwender sowie neue private Bereitstellungen und erklärt, dass sich das Interesse der Community eher auf dezentrale Identität und Nachweise als auf Ledger-Architektur konzentriert.

Indy bleibt relevant, weil es DIDs, Widerrufsregister, AnonCreds und Aussteller-Inhaber-Verifizierer-Abläufe für viele Teams konkret gemacht hat. Das Projekt berichtete zudem, dass das ältere Indy SDK bis Ende des ersten Quartals 2024 eingestellt wurde und das Ökosystem zu gemeinsam genutzten Komponenten von Aries Askar, Indy VDR und Hyperledger AnonCreds übergeht. Das ist eine Lehre für den Lebenszyklus: Ein Identitätssystem muss die Migration von Clients und Kryptografie planen, nicht nur die erste Ausstellung.

Sovrin nutzte Hyperledger Indy für ein öffentliches berechtigtes Identitätsnetzwerk. Im Februar 2025 teilte die Sovrin Foundation mit, dass sie sich nach sieben Jahren auf die wahrscheinliche Abschaltung ihres MainNet-Ledgers am oder vor dem 31. März 2025 vorbereite, nach einer Bewertung der Nachhaltigkeit des Netzwerks. Das entkräftet die vorangetriebenen Ideen nicht, zeigt aber, warum Kontinuität, Finanzierung, Steward-Betrieb, Exportwege und Resolver-Ausweichpläne in ein Identitäts-Bedrohungsmodell gehören.

Zweckgebundene Systeme können einen starken Domänenfokus und sorgfältig entworfene Datenschutzprimitive bieten. Sie können jedoch auch operative Konzentration auf ein bestimmtes Netzwerk und einen Software-Stack schaffen. Die Ethereum-artige Zusammenstellung bietet breite Kombinierbarkeit, verlagert aber mehr Koordination in die Anwendung. Keines der Modelle ersetzt Aussteller-Governance, Usability-Forschung und belastbare Schlüsselwiederherstellung.

Autheo pflegt eine DID and identity comparison page und eine ausführliche Sovrin network history. Einen aktuellen, vorsichtig formulierten Vergleich der Roadmap finden Sie unter Autheo, Indy, Sovrin, and uPort.

TheoID ist Autheos geplante souveräne Identitätsschicht. Sie ist heute nicht auf Autheo live und noch nicht in das Live-System eingebunden. Staking und Transaktionsgebühren sind heute live; Identität, Compute, Storage, KI-Inferenz und THEO AI befinden sich weiterhin in Entwicklung und werden schrittweise eingeführt.

Mit der Einführung soll TheoID an W3C DID- und Konzepte überprüfbarer Nachweise angelehnt werden, damit Personen, Organisationen, Geräte, Validatoren und Agenten interoperable Identifikatoren und signierte Aussagen nutzen können. Das geplante Modell konzentriert sich auf portable Identität, abgegrenzte Autorisierung, Verwaltung des Nachweislebenszyklus und eine gemeinsame Identitätsbasis für Anwendungen rund um Autheo.

Die Roadmap beschreibt auch Unterstützung für Post-Quanten-Kryptografie, doch dieser Schutz ist nicht live und noch nicht in das System eingebunden. Teams sollten ihre aktuellen Sicherheitskontrollen anhand dessen bewerten, was heute operativ ist, und nicht anhand künftiger Integrationspläne. Die TheoID roadmap page ist die maßgebliche Autheo-Referenz für den laufenden Status.

Für das Design von KI-Agenten ist die zentrale Idee eine begrenzte Delegation. Ein Agent sollte einen Nachweis oder eine Fähigkeit erhalten, die nach Zweck, Ressource, Betrag, Zeit und Widerrufsbedingungen begrenzt ist, statt eine Kopie der umfassenden Wallet-Befugnis eines Menschen. Diese Architektur gehört zur beabsichtigten Richtung von TheoID und ist kein heute verfügbares Produktionsmerkmal.

Autheo läuft auf Proof of Autheo, einem Hybrid PoA/PoS-Konsensmodell. Dieser Konsensmechanismus und eine Identitätsschicht lösen unterschiedliche Probleme: Der eine koordiniert Validator-Eignung und stake-gewichtete Blockproduktion, die andere soll Subjekte und ihre delegierte Befugnis repräsentieren und authentifizieren.

Beginnen Sie mit der Frage der verlassenden Partei, nicht mit einer Präferenz für eine Chain. Was muss der Verifizierer wissen? Wer kann die Aussage ausstellen? Kann der Inhaber einen Mindestnachweis vorlegen? Wie wird der Ausstellerschlüssel gefunden und was passiert nach Kompromittierung oder Widerruf? Die Antworten bestimmen, ob eine DID, ein Nachweis, eine signierte Nachricht oder ein herkömmliches föderiertes Konto geeignet ist.

Messen Sie dann den operativen Weg. Testen Sie Schlüsselrotation, Gerätemigration, Wiederherstellung nach Geräteverlust, Ausstellerwiderruf, Resolver-Ausfälle, Ablauf von Nachweisen und Support-Eskalation. Ein Identitätsdesign, das nur für eine neue Wallet in einer Demo funktioniert, ist in der Praxis keine souveräne Identitätsschicht.

Halten Sie personenbezogene Daten schließlich von öffentlichen Ledgern fern, sofern es keinen zwingenden Grund und keine rechtliche Grundlage gibt. Ledger können Hashes, öffentliche Schlüssel, Widerrufsreferenzen oder Zustandsübergänge verankern. Der Nachweis selbst, sensible Attribute und Einwilligungsdaten benötigen oft datenschutzschonende Speicherung und Offenlegungskontrollen.