← Zurück zu allen Artikeln
Identity & Architektur

DIDComm: Dezentrale Identität & Kommunikation in der Praxis

Veröffentlicht am 12. Februar 2026 · Lesezeit: 9 Minuten

1. Warum DIDComm überhaupt spannend ist

Die heutige Identity-Landschaft ist stark zentralisiert: wenige große Provider (Cloud, Social Login, SSO) kontrollieren Login-Flows, User Profiles und große Teile der Kommunikationswege. Das bringt Bequemlichkeit – aber auch klare Risiken:

  • Macht- und Datenkonzentration bei wenigen Anbietern
  • Single Points of Failure (IdP-Ausfall → viele Dienste gleichzeitig betroffen)
  • Hohe Impact-Fläche bei Data Breaches
  • Geschäftsmodelle, die stark auf Tracking und Profiling setzen

Dezentrale Identität (DID, Verifiable Credentials, DIDComm) versucht, die ursprünglichen Prinzipien des Internets wiederzubeleben: offene Protokolle, Peer-to-Peer-Kommunikation, cryptographic Trust Models statt rein institutioneller Gatekeeper.

DIDComm ist dabei kein Ersatz für SSO, sondern ein anderes Architektur-Modell: weg von „ein IdP in der Mitte“, hin zu direktem, verschlüsseltem Austausch zwischen autonomen Agents, die DIDs und Verifiable Credentials nutzen.

2. Kurz erklärt: Was ist DIDComm?

DIDComm (Decentralized Identifier Communication) ist ein Protokoll für End-to-End-verschlüsselte, authentifizierte Peer-to-Peer-Nachrichten auf Basis von DIDs.

Aus Business-Sicht:

  • Zwei Parteien (Menschen, Services, Organisationen)
    • identifizieren sich gegenseitig über DIDs,
    • tauschen Verifiable Credentials aus,
    • kommunizieren End-to-End verschlüsselt.
  • Kein zentraler Identity Provider (IdP) muss jeden Schritt sehen oder freigeben.

Aus technischer Sicht:

  • End-to-End Encryption: verschlüsselt mit dem Public Key des Empfängers, signiert mit dem Private Key des Senders.
  • Transport-agnostic: HTTP, WebSockets, Bluetooth, NFC, … – Transport wird entkoppelt vom Security-Layer.
  • Built for Verifiable Credentials: Credentials können als Teil des Message Flows angefragt, übertragen und verifiziert werden.
  • Mutual Authentication: beide Seiten können die Identität des Gegenübers über DIDs und zugehörige Keys verifizieren.

3. Funktionsweise in sehr komprimierter Form

Kernbaustein von DIDComm sind DIDs und DID Documents:

  • Jede Partei erzeugt eine DID und publiziert ein DID Document (z.B. als did:web unter einer Domain oder über eine ledger-based Methode).
  • Das DID Document enthält u.a. Public Keys und Service Endpoints – also eine cryptographic „Kontaktkarte“.

Wenn zwei Parteien kommunizieren wollen:

  1. Sie resolven gegenseitig ihre DIDs, um Keys und Endpoints zu erhalten.
  2. Sie etablieren einen DIDComm Channel, indem sie erste verschlüsselte Nachrichten austauschen und ggf. Parameter aushandeln.
  3. Alle weiteren Nachrichten sind E2E-verschlüsselt und signiert:
    • Confidentiality: nur der Empfänger kann entschlüsseln.
    • Integrity & Authenticity: Signatur beweist, von wem die Nachricht kommt und dass sie unverändert ist.
  4. Der Transport (HTTP, WebSockets, …) kann wechseln, ohne das Trust Model zu verändern.

Damit entsteht ein Communication Layer, der Identität und Vertrauen direkt zwischen den Beteiligten verankert – nicht bei einem zentralen IdP.

4. DIDComm vs. klassisches SSO – zwei Modelle

Klassische SSO-Lösungen (OAuth2, OpenID Connect, SAML) sind IdP-zentriert:

  • Ein zentraler Identity Provider (IdP)
    • authentifiziert Nutzer,
    • stellt Tokens aus,
    • sieht typischerweise jeden Login-Flow.
  • Trust Model: hierarchisch – Vertrauen fließt von einem oder wenigen zentralen Anbietern zu allen Diensten.

DIDComm verfolgt ein anderes Muster:

  • Identität wird über DIDs und Verifiable Credentials modelliert, die von verschiedenen Issuers stammen können.
  • Credentials liegen in Wallets von Nutzern oder Organisationen.
  • Verifikation erfolgt direkt zwischen Peers, basierend auf Public Keys und Vertrauensankern in den Issuers.
  • Trust Model: Netzwerk – viele Knoten, viele mögliche Issuers, flexible Policies.

Ein paar zentrale Unterschiede:

  • Ownership
    • SSO: User Records liegen primär beim IdP.
    • DIDComm: DIDs und Credentials liegen in Wallets der Nutzer/Organisationen.
  • Privacy
    • SSO: IdP sieht jeden Login und kann ein detailliertes Nutzungsverhalten ableiten.
    • DIDComm: kein zentraler Log; Selective Disclosure möglich.
  • Lock-in
    • SSO: starker Vendor Lock-in an IdP und dessen APIs.
    • DIDComm: offener Standard, interoperable Agents & Wallets sind prinzipiell portierbar.

Wichtig: Das ist kein „SSO schlecht, DIDComm gut“-Narrativ. In der Praxis werden beide Modelle koexistieren – jeweils dort, wo sie zum Kontext passen.

5. Beispiel E-Commerce: Verifiable Credentials über DIDComm

Im E-Commerce treffen mehrere Parteien aufeinander:

  • Marktplatzbetreiber
  • Händler
  • Logistik- und Payment-Provider
  • Aufsichtsbehörden / Regulatoren

Heute hat praktisch jeder seine eigene Identity- und Compliance-Strecke:

  • Wiederholtes Onboarding und KYC/AML-Prüfungen,
  • Integrationen zu diversen Registern und Payment-Providern,
  • Medienbrüche und manuelle Checks.

Ein DIDComm-basiertes Modell könnte so aussehen:

  1. Merchant Onboarding

    • Händler erhalten Verifiable Credentials (Handelsregister, USt-Id, Risk Scoring) von vertrauenswürdigen Issuers.
    • Beim Onboarding präsentiert der Händler über DIDComm lediglich die notwendigen Proofs – nicht alle Rohdaten.

  2. Compliance

    • Plattformen können gezielt cryptographic Proofs anfragen (z.B. „gilt als regulierter Zahlungsdienstleister in EU-Land X“), ohne alle Dokumente einzusehen.
    • Regulatorische Anforderungen lassen sich so präziser und mit Data Minimization erfüllen.

  3. Kunden-Interaktionen

    • Kunden könnten Credentials zu Alter, Wohnsitz oder Zahlungsfähigkeit präsentieren, ohne vollständige Identitäten offenzulegen.

Der Kern: Identität und Nachweise wandern aus zentralen Datenbanken in Wallets, während Plattformen weiterhin die Proofs erhalten, die sie wirklich brauchen.

6. Warum das für Enterprise‑IT „Signal“ ist – und kein reiner Hype

Aus Enterprise-Sicht ist DIDComm kein kurzfristiger drop-in replacement für bestehende SSO-Landschaften. Aber es adressiert einige sehr reale Probleme:

  • Macht- und Abhängigkeitsrisiken rund um große IdPs und Plattformen
  • Datenschutz-Anforderungen (Data Minimization, Privacy by Design)
  • Resilience bei Ausfällen oder Offline-Szenarien
  • Bedarf an interoperablen Identity- und Proof-Modellen über Organisationsgrenzen hinweg

Gleichzeitig bleiben Herausforderungen:

  • Usability & Key Management: Wallets müssen nutzbar und fehlertolerant sein, ohne Security zu opfern.
  • Governance: Wer gilt als vertrauenswürdiger Issuer? Wie sehen Policies und Haftungsfragen aus?
  • Ecosystem Maturity: Tools, Libraries und Best Practices entwickeln sich noch.

Aus meiner Sicht ist DIDComm deshalb ein klares Signal:

  • Es verschiebt die Diskussion von „welchen IdP sollten wir nutzen?“ hin zu „welches Trust- und Data-Flow-Modell brauchen wir?“.
  • Es zeigt einen architektonisch anderen Pfad auf, der mittelfristig relevant werden kann, selbst wenn heute erst wenige Production-Einsätze existieren.

Für Enterprise-Architekten und Plattformteams lohnt es sich, DIDComm und dezentrale Identität jetzt zu verstehen – nicht, um morgen alles umzustellen, sondern um künftige Optionen und Risiken besser einordnen zu können.