SD-JWT erklärt: Token mit selektiver Offenlegung (RFC 9901)

SD-JWT ist ein signiertes Datenformat, mit dem die Person, die einen Nachweis besitzt, nur Teile davon offenlegt. Eine Hochschule könnte Ihnen ein Token mit Name, Geburtsdatum, Anschrift und Studierendenstatus ausstellen. Fragt die Bibliothek nur, ob Sie eingeschrieben sind, legen Sie genau diese eine Angabe offen, und die Bibliothek kann trotzdem prüfen, dass die Hochschule das Token signiert hat. Die Kernspezifikation ist RFC 9901, im November 2025 von der IETF veröffentlicht.

Welches Problem löst SD-JWT?

Ein gewöhnliches signiertes Token, etwa ein JSON Web Token (JWT), kennt nur alles oder nichts. Wer eine einzige Tatsache belegen will, muss alle enthaltenen Angaben herausgeben, denn eine Änderung des Inhalts würde die Signatur brechen. Für Ausweisdaten passt das schlecht: Ein Shop, der wissen muss, ob Sie volljährig sind, braucht nicht Ihre Adresse.

SD-JWT behält die Signatur bei, macht aber die Offenlegung einzelner Angaben optional. Das ist die technische Grundlage für Datensparsamkeit, einen Grundsatz des EU-Datenschutzrechts, und ein Baustein der EUDI-Wallet.

Wie funktioniert das?

Das Prinzip heißt „gesalzene Hashes“. Drei Rollen sind beteiligt: Der Aussteller erzeugt und signiert den Nachweis, der Inhaber (Ihre Wallet) bewahrt ihn auf, und die prüfende Stelle (der Dienst, der Daten verlangt) kontrolliert ihn.

1. Ausstellung. Für jede Angabe, die verborgen werden darf, erstellt der Aussteller einen kleinen Datensatz, die Disclosure, mit einem Zufallswert (Salt), dem Namen der Angabe und ihrem Wert. In das signierte Token kommt nur der Hash jeder Disclosure, nicht die Angabe selbst.
2. Aufbewahrung. Der Inhaber erhält das signierte Token samt aller Disclosures.
3. Vorlage. Der Inhaber sendet das signierte Token und nur die Disclosures, die er zeigen will. Sie werden mit einer Tilde (~) angehängt.
4. Prüfung. Die prüfende Stelle kontrolliert die Signatur des Ausstellers, bildet den Hash jeder erhaltenen Disclosure und stellt fest, dass er im signierten Token steht. Verborgene Angaben bleiben verborgen, weil der Salt ihre Hashes unerratbar macht.

Eine vereinfachte Vorlage sieht so aus:

<vom-aussteller-signiertes-JWT>~<Disclosure: age_over_18 = true>~<Key-Binding-JWT>

Der letzte Teil, das Key-Binding-JWT, ist optional, für Identitätsnachweise aber wichtig. Der Inhaber signiert eine kurze Nachricht mit einem an den Nachweis gebundenen Schlüssel, darin eine Zufallszahl der prüfenden Stelle und deren Kennung. So ist belegt, dass die vorlegende Person diejenige ist, für die der Nachweis ausgestellt wurde, und eine gestohlene Kopie lässt sich nicht erneut einspielen.

SD-JWT, SD-JWT VC und verwandte Begriffe

• SD-JWT (RFC 9901) ist der allgemeine Mechanismus, siehe den Eintrag im IETF-Datatracker.
• SD-JWT VC ist ein Profil für verifizierbare digitale Nachweise auf Basis von SD-JWT. Es legt Nachweistypen fest und wie prüfende Stellen Aussteller-Schlüssel finden. Es ist weiterhin ein Internet-Draft der IETF-Arbeitsgruppe OAuth; im Oktober 2026 hatte es die Arbeitsgruppe durchlaufen und lag im Veröffentlichungsprozess der IESG.
• Verifiable Credentials ist das übergeordnete Konzept; unsere Seite zu Verifiable Credentials erklärt, wie die Formate zusammenhängen.

Wo nutzt die EUDI-Wallet SD-JWT?

Die Wallet-Architektur der EU, das Architecture and Reference Framework, nennt zwei Nachweisformate, die Wallets und Aussteller unterstützen müssen: ISO mdoc und SD-JWT VC. Personenidentifizierungsdaten, die digitale Entsprechung Ihrer nationalen Identität, sollen in beiden Formaten ausgestellt werden. Welches ein Dienst akzeptiert, hängt vom Anwendungsfall und vom Übertragungsweg ab: mdoc stammt aus der Nahbereichswelt des digitalen Führerscheins (siehe mdoc und ISO 18013-5), SD-JWT VC aus der Web- und OAuth-Welt.

In die Wallet gelangen Nachweise über OpenID for Verifiable Credential Issuance, an Dienste werden sie über OpenID for Verifiable Presentations übermittelt. SD-JWT ist die Nutzlast in diesen Protokollen, kein Protokoll.

Beispiele

• Altersprüfung. Die Wallet zeigt nur die Angabe age_over_18, ohne Namen und Geburtsdatum.
• Anschrift für eine Lieferung. Der Inhaber legt die Postadresse offen, nicht das Geburtsdatum.
• Mitarbeiterausweis. Ein Arbeitgebernachweis zeigt einem Partnerportal nur Firmenname und Rolle.

Sicherheit und Datenschutz: Was Sie wissen sollten

• Selektive Offenlegung ist keine Unverknüpfbarkeit. Signatur und Hashes des Ausstellers sind bei jeder Vorlage dieselben. Zwei Dienste, die Daten abgleichen, erkennen denselben Nachweis wieder. Wallets und Aussteller können das mit vielen einmal nutzbaren Kopien abmildern; RFC 9901 behandelt die Unverknüpfbarkeit ausdrücklich. Mehr dazu in unserem Artikel zum Datenschutz der EUDI-Wallet.
• Der Aussteller erfährt nichts von der Vorlage. Anders als beim klassischen Single Sign-on wird er bei der Vorlage nicht kontaktiert, was dem Datenschutz dient.
• Key Binding ist wichtig. Ohne dieses Verfahren könnte jeder, der Token und Disclosures kopiert, sie vorlegen. Prüfende Stellen sollten es bei Identitätsnachweisen verlangen.
• Salts müssen zufällig sein. Vorhersehbare Salts würden das Erraten verborgener Werte erlauben. Das liegt in der Verantwortung des Ausstellers.
• Widerruf braucht einen eigenen Mechanismus. SD-JWT regelt nicht, wie ein Nachweis zurückgezogen wird; dafür dienen Statuslisten, die separat spezifiziert sind.

Vergleich mit anderen Standards

Format	Kodierung	Selektive Offenlegung	Typischer Einsatz
SD-JWT VC	JSON, JWS	Gesalzene Hashes	Online- und Web-Abläufe, OAuth-nahe Wallets
ISO mdoc	CBOR, COSE	Gesalzene Hashes der Datenelemente	Nahbereich (NFC, QR, Bluetooth) und online
W3C VC mit JSON-LD-Beweisen	JSON-LD	Abhängig vom Beweisverfahren	Forschung, einzelne Pilotprojekte

SD-JWT und mdoc folgen demselben Prinzip, Angaben hinter gesalzenen Prüfsummen zu verbergen, unterscheiden sich aber in Kodierung und Umfeld. Einen Gesamtüberblick, wie eine Wallet arbeitet, bietet die Übersicht zur EUDI-Wallet.

Stand im Oktober 2026

RFC 9901 ist abgeschlossen und stabil. SD-JWT VC steht kurz vor der Veröffentlichung, ist aber noch kein RFC; Details können sich ändern, Entwickler sollten dem jeweils aktuellen Entwurf folgen. Die technischen Spezifikationen der EU für Wallets verweisen auf diese Dokumente und werden regelmäßig aktualisiert; prüfen Sie vor dem Bauen stets die aktuelle Fassung des Architekturrahmens.