SD-JWT VC vs. mdoc (ISO/IEC 18013-5): Formate der EUDI-Wallet im Vergleich

Zuletzt geprüft: 5. Oktober 2026 · Keine Rechtsberatung

Ein SD-JWT VC ist ein verifizierbares Credential, verpackt als signiertes JSON Web Token, dessen Claims einzeln offengelegt werden können. Ein mdoc ist ein mobiles Dokument im Format von ISO/IEC 18013-5, dem Standard, der ursprünglich für mobile Führerscheine geschrieben wurde. Das Architecture and Reference Framework (ARF) der EUDI-Wallet führt beide als verpflichtend für Wallets auf. Ein drittes Format, das W3C Verifiable Credentials Data Model 2.0, ist optional und „nur für nicht qualifizierte EAAs gedacht“.^[1]

Dieser Leitfaden vergleicht die beiden Formate für Entwickler, die einen Verifier bauen. Grundlage sind das ARF v3.0.0, der Text von OpenID for Verifiable Presentations (OpenID4VP) 1.0 und das Amtsblatt. PID steht für Personenidentifizierungsdaten.

Was ein SD-JWT VC ist

Das ARF beschreibt „SD-JWT-based Verifiable Credentials“ als Datenformat und Verarbeitungsregeln zur Darstellung verifizierbarer Credentials, wobei SD-JWT „für ‚Selectively Disclosable JSON Web Token‘ steht“.^[1] Es umfasst die JSON-Kodierung, einen Nachweismechanismus mit selektiver Offenlegung und eine optionale Gerätebindung.^[1]

In OpenID4VP lautet der Formatbezeichner dc+sd-jwt, und eine Abfrage benennt den Credential-Typ über vct_values.^[4] Das Beispiel der Spezifikation für einen ausgestellten Payload, gekürzt auf zwei seiner acht Digests:^[4]

{ "_sd": [ "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4", "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo" ], "vct": "https://credentials.example.com/identity_credential", "_sd_alg": "sha-256", "cnf": { "jwk": { "kty": "EC", "crv": "P-256" } } }

Was ein mdoc (ISO/IEC 18013-5) ist

ISO/IEC 18013-5 definiert die Führerscheinattribute, ihre Kodierung in Concise Binary Object Representation (CBOR), Namespaces, die Kollisionen von Bezeichnern verhindern, einen Nachweismechanismus mit selektiver Offenlegung, eine verpflichtende Gerätebindung und den Austausch im Nahbereich.^[1]

Nur das Datenmodell des Führerscheins ist fahrspezifisch. Das ARF hält fest, dass alle anderen Aspekte „generisch sind und für jeden anderen Attestierungstyp verwendet werden können, einschließlich PIDs“.^[1]

OpenID4VP beschreibt diese Credentials als „in CBOR kodiert und mit COSE_Sign1 gesichert“ und vergibt den Formatbezeichner mso_mdoc. Eine Abfrage benennt den Dokumenttyp über doctype_value.^[4]

Wie die selektive Offenlegung in jedem Format funktioniert

Selektive Offenlegung ermöglicht es dem Nutzer, einige Attribute zu teilen und den Rest zu verbergen, während der Verifier weiterhin die Signatur des Ausstellers prüft. eIDAS 2 verpflichtet Wallets, dies zu ermöglichen.^[6] Das ARF bezeichnet den SD-JWT-Mechanismus als „gesalzene Hashes“ und erklärt, er sei „konzeptionell identisch mit dem Mechanismus, der in [ISO/IEC 18013-5] für denselben Zweck verwendet wird“.^[1]

Ein Mechanismus, zwei Kodierungen.^[1][4]

Im obigen Beispiel enthält das Array _sd SHA-256-Digests. Jede Disclosure ist ein Array aus einem Zufallswert, dem Namen des Claims und dem Wert des Claims. Für den Vornamen lautet sie ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"], und ihr Hash ist der erste Digest in der Liste. Der Prüfer hasht jede empfangene Disclosure und sucht den Digest im signierten Payload.^[4]

Claims werden unterschiedlich adressiert. Bei einem JSON-Credential ist ein Claims-Pfad eine Liste von Schlüsseln wie ["address", "street_address"]. Bei einem mdoc „enthält“ der Pfad „zwei Elemente vom Typ String“: den Namespace und den Bezeichner des Datenelements, zum Beispiel ["org.iso.18013.5.1", "first_name"].^[4]

Key Binding und Device Engagement

Die Gerätebindung knüpft ein Credential an Schlüssel in der Wallet des Nutzers, sodass es nicht geklont werden kann. Der Prüfer kontrolliert sie, indem er die Wallet auffordert, frische Zufallsdaten mit dem privaten Schlüssel zu signieren, der zum öffentlichen Schlüssel im Credential passt.^[1] Die Bezeichnungen unterscheiden sich: „In [ISO/IEC 18013-5] heißt es ‚mdoc authentication‘. In [SD-JWT VC] heißt es ‚key binding‘.“^[1]

Die Gerätebindung ist für PIDs in beiden Formaten verpflichtend.^[1][4]

Für SD-JWT VC ist die Regel in OpenID4VP streng. Wenn require_cryptographic_holder_binding auf true gesetzt ist, was der Standardwert ist, „MUSS die Wallet ein SD-JWT zurückgeben“, und zwar mit einem Key Binding JWT. Der Claim nonce muss der Nonce Ihrer Anfrage entsprechen, und aud muss Ihrem Client Identifier entsprechen. Ausnahme ist die Digital Credentials API: Dort muss er Ihrem Origin mit dem Präfix origin: entsprechen.^[4]

Device Engagement gibt es nur bei mdoc. In einem Ablauf im Nahbereich zeigt der Nutzer einen QR-Code oder präsentiert ein NFC-Tag. Es enthält, was das Lesegerät braucht, um eine NFC-, Bluetooth-Low-Energy- oder Wi-Fi-Aware-Verbindung zu öffnen und darauf einen authentifizierten, verschlüsselten Kanal aufzubauen. Eine Internetverbindung zwischen beiden ist nicht nötig.^[1]

Eine Präsentation im Nahbereich mit mdoc (ISO/IEC 18013-5), vereinfacht.^[1]

Was der Nutzer sieht:

Präsentationsprotokolle: OpenID4VP, ISO/IEC 18013-7 und Nahbereich

Das ARF listet auf, was eine Wallet verarbeitet: ISO/IEC 18013-5 im Nahbereich sowie OpenID4VP oder ISO/IEC 18013-7 aus der Ferne.^[1]

Welches Protokoll welches Format transportiert, laut ARF.^[1]

Attestierungen im Format SD-JWT VC „können nicht für Präsentationen im Nahbereich verwendet werden“. ISO/IEC 18013-7 „kann nur verwendet werden, um Attestierungen im [ISO/IEC 18013-5]-konformen Format anzufordern und zu präsentieren“. OpenID4VP „eignet sich nur für Transaktionsabläufe bei der Fernpräsentation“ und transportiert beide Formate.^[1] OpenID4VP 1.0 wurde am 10. Juli 2025 zur Final Specification.^[5]

Das ARF empfiehlt keine benutzerdefinierten URI-Schemata über Geräte hinweg, weil diese Abläufe „anfällig für Phishing- und Relay-Angriffe sind“, und nennt die Digital Credentials API als Alternative.^[1] Diese API ist noch ein W3C-Entwurf, und Chrome 141 aktiviert sie standardmäßig.^[9][10] ISO führt die technische Spezifikation von 18013-7 aus dem Jahr 2024 als zurückgezogen und ersetzt, eine dritte Ausgabe ist in Entwicklung. Prüfen Sie daher, auf welche Ausgabe Ihr Code ausgerichtet ist.^[7][8] Details zur Anfrage finden Sie im Leitfaden für OpenID4VP-Verifier.

Was die Durchführungsverordnung (EU) 2026/1731 für die PID verlangt

Die erste Vorschrift zu PID-Formaten, die Durchführungsverordnung (EU) 2024/2977, legte fest, dass die PID „in zwei Formaten ausgestellt“ wird: ISO/IEC 18013-5:2021 und das Verifiable Credentials Data Model 1.1.^[2][3] Der Änderungsrechtsakt vom Juli 2026 ersetzte diesen Satz. Die PID wird nun „gemäß den Normen ausgestellt, die in Anhang II der Durchführungsverordnung (EU) 2024/2979, Abschnitte 5 (Format SD-JWT VC) und 6 (Format ISO/IEC-mdoc), festgelegt sind“.^[2]

1. 4. Dezember 2024Erste Vorschrift2024/2977: 18013-5 und VCDM 1.1.
2. 22. Juli 2026Geändert2026/1731: SD-JWT VC und mdoc.
3. 23. Juli 2026ARF v3.0.0An die Änderungsrechtsakte angepasst.
4. 24. Dezember 2026Bereitstellung der WalletsEine Wallet pro Mitgliedstaat.
5. 11. August 2028LichtbildDie Anforderung an das Lichtbild gilt, sofern der Nutzer nicht ausdrücklich widerspricht, soweit anwendbar.

Wie sich das Recht zu PID-Formaten entwickelt hat.^[1][2][3][6]

Derselbe Rechtsakt legt in seinem Anhang zur Durchführungsverordnung (EU) 2024/2982 zwei Präsentationsprofile fest: ein „ISO/IEC-mdoc-Profil“ und ein „OpenID4VC-HAIP-Profil“.^[2]

• Senden Sie Ihr Registrierungszertifikat: Ein Element von verifier_info „muss das Registrierungszertifikat enthalten“.^[2]
• Verwenden Sie Ihr Zugangszertifikat als Leaf-Zertifikat mit dem Client-Identifier-Präfix x509_hash.^[2]
• Befolgen Sie für mdoc über die Digital Credentials API „Anhang C der ISO/IEC 18013-7:2025“.^[2]

Die Registrierung behandelt der Leitfaden für vertrauende Beteiligte der EUDI-Wallet, den Zeitplan der Beitrag Fristen der EUDI-Wallet für 2026 und 2027.

SD-JWT VC vs. mdoc (ISO/IEC 18013-5): Vergleichstabelle

Aus dem ARF, außer der PID-Zeile (Durchführungsverordnung 2026/1731) und den letzten beiden Zeilen (OpenID4VP 1.0).^[1][2][4]

Mobile Führerscheine in den Vereinigten Staaten stützen sich für den Nahbereich auf ISO/IEC 18013-5.^[7][8] Die EU-Lösung zur Altersverifikation nennt Zero-Knowledge-Proof als verpflichtenden Präsentationsmechanismus, „mit einfacher mDoc-Präsentation als Fallback“.^[13] Die EVO Wallet aus Moldau dokumentiert OpenID4VP 1.0 mit einem mdoc nach ISO/IEC 18013-5, profiliert nach HAIP 1.0.^[11]

Welches Format ein vertrauender Beteiligter unterstützen muss

Wallet-Einheiten verarbeiten beide Formate, und die PID wird in beiden ausgestellt.^[1][2] Die für diesen Leitfaden gelesenen Texte enthalten keine Stelle, die einen vertrauenden Beteiligten verpflichtet, beide anzufordern. Die praktische Lesart: Ein Verifier aus der Ferne kann eines der beiden anfordern, und ein Lesegerät ohne Internetverbindung braucht mdoc, das einzige Format, das im Nahbereich funktioniert.^[1]

Mit der Digital Credentials Query Language (DCQL) in OpenID4VP kann eine Anfrage eine dc+sd-jwt-Abfrage und eine mso_mdoc-Abfrage nebeneinander enthalten; die Spezifikation zeigt eine solche Anfrage.^[4] Nach dem ARF prüft der vertrauende Beteiligte die Signatur des Ausstellers gegen einen Vertrauensanker aus einer Trusted List oder einer List of Trusted Entities, prüft den Widerruf über eine Statusliste oder eine Widerrufsliste und prüft die Gerätebindung.^[1]

Nach eIDAS 2, Verordnung (EU) 2024/1183, muss jeder Mitgliedstaat bis zum 24. Dezember 2026 mindestens eine Wallet bereitstellen, und private vertrauende Beteiligte, die zur starken Nutzerauthentifizierung verpflichtet sind, müssen sie bis zum 24. Dezember 2027 auf Verlangen des Nutzers akzeptieren; Kleinst- und Kleinunternehmen sind ausgenommen.^[6] Der Stand je Land steht im Tracker zum Start der EUDI-Wallet.

Bibliotheken und Testwerkzeuge

Die Quellen hinter diesem Leitfaden nennen keine Open-Source-Bibliotheken, daher nennt auch dieser Abschnitt keine. Sie sagen aber, wo Sie testen sollten und was Sie bei jeder gewählten Bibliothek prüfen sollten.

• Führen Sie die Konformitätstests unter conformance.eudi.dev durch, die in den Release Notes zu ARF v3.0.0 genannt werden.^[1]
• Lesen Sie die Dokumentation der Referenzimplementierung unter docs.eudi.dev.^[1]
• Sehen Sie sich einen veröffentlichten Verifier an: Die Nationalbank der Republik Moldau hat einen Demo-Verifier mit Quellcode für Finanzinstitute veröffentlicht.^[12]
• Prüfen Sie, dass die Bibliothek HAIP folgt und nicht nur den Basisspezifikationen.^[1]
• Prüfen Sie, welche Ausgabe von ISO/IEC 18013-7 sie implementiert.^[2][8]

Wie Didit bei der Verifizierung mit der EUDI-Wallet hilft

Die Akzeptanz der EUDI-Wallet ist bei Didit in Kürze verfügbar. Sie steht auf unserer Roadmap, abgestimmt auf den Zeitplan der EUDI-Wallet, im selben Workflow, den Sie heute nutzen. Personen aus der Ferne verifizieren können Sie schon jetzt.

• Fünf nationale eIDs laufen heute in Didit über digitale ID-Wallets: MitID, BankID Sweden, Finnish Trust Network, Smart-ID und Mobile-ID. Siehe eID-Verifizierung.
• Alle anderen nutzen die Dokumentenverifizierung mit Auslesen des NFC-Chips, Liveness-Prüfung und Gesichtsabgleich. Ein vollständiger KYC-Check kostet $0.33.
• Das AML-Screening läuft im selben Ablauf für $0.20.

Die Wallet-Dokumentation zeigt, wie eIDs pro Land aktiviert werden.

Häufig gestellte Fragen

Quellen

1. Architecture and Reference Framework v3.0.0, eu-digital-identity-wallet auf GitHub, Release vom 23. Juli 2026.
2. Durchführungsverordnung (EU) 2026/1731 der Kommission, EUR-Lex, Amtsblatt vom 22. Juli 2026.
3. Durchführungsverordnung (EU) 2024/2977 der Kommission über Personenidentifizierungsdaten, EUR-Lex, Amtsblatt vom 4. Dezember 2024.
4. OpenID for Verifiable Presentations 1.0, OpenID Foundation, finale Spezifikation.
5. OpenID for Verifiable Presentations 1.0 Final Specification Approved, OpenID Foundation, 10. Juli 2025.
6. Verordnung (EU) 2024/1183 (eIDAS 2), EUR-Lex, Amtsblatt vom 30. April 2024.
7. Normenreihe ISO/IEC 18013, mobiler Führerschein, ISO-Normseite.
8. ISO/IEC 18013-7, ISO-Normseite.
9. Digital Credentials, W3C-Entwurf.
10. Digital Credentials API shipped, Chrome for Developers.
11. Entwicklerleitfaden für EVO Wallet, Regierung der Republik Moldau, egov4dev.
12. Demo-Verifier der BNM, Regierung der Republik Moldau, egov4dev.
13. EU-Lösung zur Altersverifikation, technisches Portal, ageverification.dev.

SD-JWT VC und mdoc (ISO/IEC 18013-5) sind zwei Kodierungen desselben Versprechens: signierte Attribute, die der Nutzer kontrolliert. Wie Didit die Akzeptanz von Wallets angeht, sehen Sie auf der Lösungsseite zur EUDI-Wallet. Alle nationalen Verfahren finden Sie in eID-Verfahren nach Land.