Sie wählen nicht eines aus. Der EUDI-Rahmen verlangt Unterstützung für beide, und das Architektur- und Referenzrahmenwerk ordnet sie bereits zu: die Vorlage in räumlicher Nähe folgt ISO/IEC 18013-5, die entfernte Vorlage läuft über OpenID for Verifiable Presentations, wo beide Formate profiliert sind.
Die eigentliche Entscheidung ist also die Reihenfolge. Legen Ihre Nutzer entfernt vor, in einem Browser oder einer App, bauen Sie zuerst SD-JWT VC. Legen sie persönlich vor, an einem Schalter oder einer Sperre, bauen Sie zuerst ISO mdoc.
Die datierte Tatsache, die den Großteil der Diskussion klärt, ist eine Durchführungsverordnung der Kommission. Das OpenID4VC High Assurance Interoperability Profile in Version 1.0 wird in der CIR (EU) 2026/1731 referenziert, und dieses Profil deckt OpenID for Verifiable Credential Issuance, OpenID for Verifiable Presentations, IETF SD-JWT VC und ISO mdoc gemeinsam in einem Dokument ab. Das ist die Antwort auf die Frage, welches das europäische Format ist. Beide.
Welche konkreten Unterschiede treffen Sie in der Umsetzung?
Lässt Ihnen der ARF tatsächlich die Wahl?
Nicht beim Vorlagemodus, dem Teil, den die meisten für eine Wahl halten. Das Architektur- und Referenzrahmenwerk ist eindeutig. Für entfernte Vorlageabläufe implementiert die Wallet OpenID for Verifiable Presentations. Für Vorlageabläufe in räumlicher Nähe hält sie sich an ISO/IEC 18013-5. Diese Entscheidung ist bereits getroffen und deckt sich nahezu genau mit den beiden Formaten, denn ISO 18013-5 ist sowohl ein Format als auch ein Nahbereichsprotokoll.
Spielraum haben Sie bei entfernten Abläufen. In OpenID4VP sind sowohl mso_mdoc als auch dc+sd-jwt gültig, und das High-Assurance-Profil deckt die kombinierte Ausgabe beider ab. Ein rein entfernt arbeitender Dienst kann daher sinnvoll allein mit SD-JWT VC beginnen und mdoc später ergänzen. Ob die Pflicht Sie überhaupt trifft, ist eine eigene Frage, behandelt in welche Sektoren die EUDI-Wallet akzeptieren müssen. Die umgebende technische Arbeit steht in unserem Leitfaden zur Relying-Party-Integration.
Was bedeutet der Draft-Status von SD-JWT VC für ein Projekt, das jetzt beginnt?
Es bedeutet, dass das Festschreiben der Version eine echte Aufgabe ist, keine Formalität. SD-JWT ist RFC 9901 und stabil. SD-JWT VC ist draft-ietf-oauth-sd-jwt-vc-18, datiert 3. August 2026, auf dem Standards Track und noch kein RFC. Die Europäische Kommission hat Draft 11 vom Oktober 2025 bewertet und keine Lücken festgestellt, mit dem Hinweis, dass sich die Spezifikation noch weiterentwickelt und nach Fertigstellung erneut zu bewerten ist.
Das Ökosystem hat auf genau dieses Problem reagiert. Im Oktober 2025 haben sowohl OpenID4VCI als auch OpenID4VP die referenzierte SD-JWT-VC-Version festgeschrieben, und das High-Assurance-Profil folgte. Die praktische Antwort ist daher nicht, dem neuesten Draft zu folgen. Sie besteht darin, dem Draft zu folgen, den das Profil festgeschrieben hat, dem Sie entsprechen, und diese Versionsnummer in Ihrer eigenen Dokumentation festzuhalten.
Was müssen Sie auf der Prüferseite tatsächlich bauen?
Die Formate unterscheiden sich, die umgebende Arbeit ist jedoch weitgehend dieselbe, weshalb die Formatentscheidung kleiner ist, als sie wirkt. Beiden gemeinsam: das Erstellen der Vorlageanfrage, wobei aktuelle OpenID4VP-Arbeit DCQL statt früherer Presentation-Definition-Ansätze verwendet. Das Auflösen von Vertrauen, was im europäischen Kontext die Auflösung von ETSI-Vertrauenslisten und der Liste der Vertrauenslisten bedeutet, ein anderes Modell als die Zertifikatskettenprüfung beim portugiesischen Bürgerausweis. Die Prüfung der Inhaberbindung, wo sie durchgesetzt wird. Die Statusprüfung. Und die Entscheidung, was aufbewahrt wird, nämlich ein Nachweis, dass eine Prüfung stattgefunden hat, und keine Kopie des Nachweises.
Was bauen Sie also zuerst?
Vier Fragen, in dieser Reihenfolge. Die erste, die eine klare Antwort liefert, entscheidet. Legen Nutzer jemals persönlich vor, an einem Schalter, einer Sperre oder einem Gerät, dann ISO mdoc zuerst, denn Nahbereich ist 18013-5 und es gibt keinen anderen Weg. Ist jede Interaktion entfernt, dann SD-JWT VC zuerst, wegen der geringeren Integrationskosten. Wissen Sie bereits, in welchem Format Ihre erste reale Gegenpartei ausstellt, dann passen Sie sich an, denn gegen etwas Echtes zu testen wiegt mehr als eine Architekturpräferenz. Und bauen Sie für einen Sektor, in dem der mDL der primäre Nachweis ist, etwa Verkehr oder Fahrzeugvermietung, dann mdoc zuerst, und rechnen Sie damit, dass es primär bleibt.
Und eine Architekturanweisung, die jede dieser Antworten überdauert. Halten Sie die Formatbehandlung hinter einer Schnittstelle, und lassen Sie die Anwendungslogik fragen, was geprüft wurde und auf welchem Vertrauensniveau, niemals was der Nachweis strukturell enthielt. Das zweite Format kommt. Ob in sechs Monaten oder in zwei Jahren, die Kosten seiner Ergänzung werden durch eine Entscheidung festgelegt, die Sie jetzt treffen.
Häufig gestellte Fragen
Die zwei Formate
Was ist der Unterschied zwischen SD-JWT VC und ISO mdoc?
Verlangt die EUDI-Wallet beide Nachweisformate?
Standardstatus und Kennungen
Ist SD-JWT VC ein fertiger Standard?
Welche Nachweisformat-Kennungen gibt es in OpenID4VP?
Reihenfolge
Welches Format sollte ein rein entfernt arbeitender Dienst zuerst umsetzen?
Kann man es vermeiden, CBOR zu unterstützen?
