SD-JWT VC oder W3C Verifiable Credentials? Der Vergleich
Für digitale Nachweise gibt es zwei grosse Familien. SD-JWT VC baut auf JSON Web Tokens auf, W3C Verifiable Credentials auf einem Datenmodell in JSON-LD. Für Agenten-Mandate im DACH-Raum spricht vieles für SD-JWT VC.
Leutrim Miftaraj, Gründer, Innopulse Consulting GmbH
Veröffentlicht am
Das Wichtigste in Kürze
- SD-JWT VC baut auf JWT auf und bringt selektive Offenlegung und Key Binding mit.
- W3C Verifiable Credentials 2.0 ist ein Datenmodell in JSON-LD mit verschiedenen Sicherungsarten.
- Im DACH-Raum spricht vieles für SD-JWT VC, weil die Schweizer E-ID und die EUDI-Wallet darauf setzen.
Worum es geht
SD-JWT VC ist ein Format der IETF: ein signiertes JWT, dessen Angaben als Hashwerte enthalten sind und einzeln offengelegt werden können. W3C Verifiable Credentials 2.0 ist ein Datenmodell des W3C, seit Mai 2025 Empfehlung, das Aussteller, Inhaber und Angaben in JSON-LD beschreibt und verschiedene Sicherungsarten zulässt.
Beide verfolgen dasselbe Ziel: Nachweise, die ein Aussteller signiert, ein Inhaber aufbewahrt und eine Prüfstelle unabhängig prüft. Sie unterscheiden sich in Kodierung, Werkzeugen und Verbreitung.
Der Vergleich
| Merkmal | SD-JWT VC | W3C VC 2.0 |
|---|---|---|
| Herkunft | IETF | W3C |
| Kodierung | JWT, kompakt | JSON-LD, erweiterbar über Kontexte |
| Selektive Offenlegung | eingebaut über Disclosures | je nach Sicherungsart, etwa über besondere Kryptosuiten |
| Sicherung | JWS mit gängigen Algorithmen | Data Integrity, JOSE oder COSE |
| Bindung an den Inhaber | Key-Binding-JWT | je nach Profil |
| Staatliche Wallets | Schweizer E-ID, EUDI-Wallet | in einzelnen Ökosystemen |
| Prüfung in KYA | vollständig | nicht unterstützt, wird gemeldet |
Wann was passt
- SD-JWT VC: Nachweise im Umfeld der Schweizer E-ID oder der EUDI-Wallet, Agenten-Mandate mit selektiver Offenlegung, Umgebungen mit bestehender JWT-Infrastruktur.
- W3C VC: Ökosysteme, die bereits darauf aufbauen, etwa im Bildungsbereich, oder Anwendungen, die die Erweiterbarkeit von JSON-LD brauchen.
- Beide: Aussteller, die verschiedene Prüfstellen bedienen, können denselben Inhalt in beiden Formaten ausstellen.
Bedeutung für Agenten-Mandate
Für Mandate zählen drei Eigenschaften: selektive Offenlegung, damit Agenten nur nötige Angaben zeigen; Key Binding, damit nur der berechtigte Agent ein Mandat vorlegen kann; und Verbreitung bei Prüfstellen. SD-JWT VC bringt die ersten beiden eingebaut mit und ist in den staatlichen Wallets der Schweiz und der EU gesetzt. Das KYA-Prüfprofil beschreibt Mandate deshalb als SD-JWT VC.
Rolle von KYA
KYA prüft SD-JWT VC vollständig, inklusive Disclosures, Key Binding, Widerruf und Delegation. W3C VC mit Data-Integrity-Beweisen meldet der Prüfkern als nicht unterstütztes Format, statt sie stillschweigend als gültig oder ungültig zu bewerten. Zum Lesen eines SD-JWT eignet sich der SD-JWT-Decoder.
Häufige Missverständnisse
- «Die Formate sind Konkurrenten, eines wird verschwinden.» Beide haben eigene Ökosysteme; viele Aussteller werden beide bedienen.
- «W3C VC kann keine selektive Offenlegung.» Mit passenden Kryptosuiten schon, aber nicht in jedem Profil und nicht bei jeder Prüfstelle.
- «SD-JWT VC ist nur für staatliche Ausweise.» Das Format eignet sich für jede Art von Nachweis, auch für Mandate und Agent Passports.
Entscheidungshilfe in drei Fragen
- Welche Wallets und Prüfstellen müssen den Nachweis verstehen? Im Umfeld der Schweizer E-ID und der EUDI-Wallet ist es SD-JWT VC.
- Brauchen Sie selektive Offenlegung ohne besondere Kryptografie? Dann spricht vieles für SD-JWT VC.
- Bauen Sie auf ein bestehendes JSON-LD-Ökosystem? Dann kann W3C VC passender sein.
Migration zwischen den Formaten
Ein Wechsel ist kein Umbau des Inhalts: Aussteller, Inhaber, Angaben und Gültigkeit lassen sich abbilden. Aufwand entsteht bei Sicherung, Schlüsselverwaltung und Prüfstellen. Wer heute mit SD-JWT VC beginnt, bleibt nahe an den staatlichen Infrastrukturen im DACH-Raum.
Häufige Fragen
Ist SD-JWT VC ein Standard?
SD-JWT VC wird in der IETF entwickelt; das zugrunde liegende SD-JWT ist weit fortgeschritten. Staatliche Wallets setzen das Format bereits ein.
Warum nutzt die Schweizer E-ID SD-JWT VC?
Weil es kompakt ist, selektive Offenlegung eingebaut mitbringt und auf verbreiteten JWT-Werkzeugen aufbaut. Auch das EU-Rahmenwerk für die EUDI-Wallet sieht SD-JWT VC vor.
Kann ein W3C VC selektiv offengelegt werden?
Ja, mit passenden Sicherungsarten, etwa besonderen Kryptosuiten. Das ist aber nicht in jedem Profil eingebaut und muss von Prüfstellen unterstützt werden.
Welches Format sollte ein Agenten-Mandat haben?
Im DACH-Raum spricht vieles für SD-JWT VC, weil staatliche Identitäten darauf aufbauen und Key Binding sowie selektive Offenlegung eingebaut sind. Das KYA-Prüfprofil verwendet SD-JWT VC.
Kann ich einen Nachweis in beiden Formaten ausstellen?
Ja. Derselbe Inhalt lässt sich als SD-JWT VC und als W3C VC ausstellen, etwa wenn verschiedene Prüfstellen verschiedene Formate verlangen.
Was bedeutet das für bestehende KYA-Prüfungen?
Nichts. KYA prüft SD-JWT VC vollständig und meldet andere Formate ausdrücklich als nicht unterstützt, statt sie falsch zu bewerten.
Welches Format nutzt ISO mdoc?
ISO mdoc ist ein drittes Format aus der Norm für mobile Führerausweise, kodiert in CBOR. Das EU-Rahmenwerk sieht es neben SD-JWT VC vor, vor allem für Nachweise, die auch offline vorgelegt werden.
Quellen
- SD-JWT VC (IETF): https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
- W3C: Verifiable Credentials Data Model v2.0: https://www.w3.org/TR/vc-data-model-2.0/
- EUDI Wallet: Architecture and Reference Framework: https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/