Leitfaden für OpenID4VP-Verifier: die EUDI-Wallet akzeptieren

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

Mit OpenID4VP bittet eine Website oder App eine Wallet, etwas über eine Person nachzuweisen, etwa einen Namen oder ein Geburtsdatum. Der Verifier gibt an, welche Nachweise und Claims er benötigt. Der Nutzer stimmt in der Wallet zu, und die Wallet gibt eine Präsentation zurück, die der Verifier kryptografisch prüft. In den Worten der Spezifikation selbst "definiert sie ein Protokoll zum Anfordern und Präsentieren von Credentials".^[1]

Dieser Leitfaden richtet sich an Entwickler, die einen OpenID4VP-Verifier für die EUDI-Wallet bauen. Er behandelt das Request-Objekt, DCQL, Response Modes, Geräteabläufe, die Prüfung von SD-JWT VC und mdoc, die HAIP-Regeln im EU-Recht, häufige Fehler und Testmöglichkeiten.

OpenID4VP in einfachen Worten

OpenID4VP übernimmt die Struktur eines OAuth 2.0 Authorization Request. Der Verifier fordert den Response Type vp_token an, und eine erfolgreiche Antwort muss einen Parameter vp_token mit den Präsentationen enthalten.^[1] Es gibt keinen Code und kein Access Token zum Austausch: Die Daten kommen mit der Antwort.

Die Wallet authentifiziert den vertrauenden Beteiligten, prüft, dass er nicht mehr anfragt, als er registriert hat, holt die Zustimmung des Nutzers ein und signiert die Präsentation. Der vertrauende Beteiligte prüft anschließend die Issuer-Signatur, den Widerrufsstatus und die Gerätebindung.^[3] Die Personenidentifizierungsdaten (PID) werden in zwei Formaten ausgegeben, SD-JWT VC und ISO/IEC mdoc. Beide nutzen gesalzene Hashes, damit der Nutzer einige Attribute teilen und den Rest verbergen kann.^[5][3]

1. 10. Juli 2025Finale SpezifikationOpenID4VP 1.0 genehmigt.
2. 22. Juli 2026VeröffentlichtCIR 2026/1731 (angenommen am 15. Juli 2026) im Amtsblatt.
3. 23. Juli 2026ARF v3.0.0Aktuelle Version der Architektur.
4. 24. Dezember 2026WalletsMindestens eine pro Mitgliedstaat.
5. 24. Dezember 2027AkzeptanzRegulierte private vertrauende Beteiligte.

Von der finalen Spezifikation bis zum Akzeptanzdatum für den Privatsektor.^[2][3][4][5]

So funktioniert der Austausch mit einem OpenID4VP-Verifier

OpenID4VP veröffentlicht ein Referenzdesign für den Response Mode direct_post, bei dem die Wallet die Antwort an einen Server-Endpunkt sendet, statt sie über den Browser zu leiten.^[1]

Das direct_post-Referenzdesign in OpenID4VP 1.0, Abschnitt 13.3, vereinfacht.^[1]

• Pro Anfrage eine Nonce aus „mindestens 16 frischen, kryptografisch zufälligen Bytes“ erzeugen.
• Die request-id vom Response-Endpunkt als state an die Wallet senden.
• Eine Redirect-URI mit einem frischen response_code zurückgeben, sobald die Wallet ihre Antwort per POST sendet.
• Den VP Token mit der transaction-id und diesem Code abrufen, dann die Nonce prüfen.

Der response_code verhindert Session Fixation, bei der ein Angreifer Ihre Anfrage an die Wallet eines Opfers weiterleitet. Die Spezifikation weist darauf hin, dass er bei geräteübergreifenden Abläufen nicht hilft, und empfiehlt dort zusätzliche Mechanismen.^[1]

Das OpenID4VP-Request-Objekt und Client Identifier

Die client_id beginnt mit einem Client Identifier Prefix, das der Wallet mitteilt, wie sie den Verifier authentifiziert.^[1] Große Anfragen werden per Referenz übermittelt: Die Wallet ruft das signierte Request-Objekt von einer request_uri ab. Für QR-Codes empfiehlt die Spezifikation direct_post mit request_uri, da die Anfrage „möglicherweise nicht in einen QR-Code passt“.^[1]

Client Identifier Prefixes, OpenID4VP 1.0, Abschnitt 5.9.^[1]

Für EUDI-Verifier legt das EU-Recht das Präfix fest: Das Endzertifikat „zur Verwendung mit dem x509_hash Client Identifier Prefix muss ein RP-Zugangszertifikat gemäß ETSI TS 119 475 sein“, und ein Element von verifier_info „muss das Registrierungszertifikat enthalten“.^[5]

DCQL-Abfragen: Fragen Sie nur an, was Sie registriert haben

Die Digital Credentials Query Language (DCQL) ist die JSON-Abfrage, die die gewünschten Credentials und Claims benennt. Sie enthält ein verpflichtendes Array credentials und ein optionales Array credential_sets. Jede Credential-Abfrage braucht eine id, ein format und ein meta-Objekt.^[1] Das SD-JWT VC-Beispiel der Spezifikation:^[1]

{ "credentials": [ { "id": "my_credential", "format": "dc+sd-jwt", "meta": { "vct_values": [ "https://credentials.example.com/identity_credential" ] }, "claims": [ {"path": ["last_name"]}, {"path": ["first_name"]}, {"path": ["address", "street_address"]} ] } ] }

Bei einem mdoc ist das Format mso_mdoc, und meta enthält einen doctype_value.^[1] Für die PID setzen Sie deren Typ und Claim-Namen ein. Die Pflichtattribute der PID sind Familienname, Vorname, Geburtsdatum, Geburtsort und Staatsangehörigkeit.^[7]

• require_cryptographic_holder_binding ist standardmäßig true. Behalten Sie das bei: Dann liefert die Wallet einen Key-Binding-Nachweis zurück.^[1]
• trusted_authorities filtert nur, was die Wallet anbietet. Verifier „müssen selbst prüfen, ob der Aussteller einer erhaltenen Präsentation vertrauenswürdig ist“.^[1]
• Vertrauende Beteiligte „dürfen von Nutzern keine anderen Daten verlangen als“ die registrierten, und die Wallet prüft das.^[4][3]

OpenID4VP-Response-Modes

Der Response Mode bestimmt, wie das VP Token zurückgelangt. Standard für vp_token ist fragment, also im Fragment der Redirect-URI.^[1]

Response-Modi in OpenID4VP 1.0.^[1]

Bei direct_post ist response_uri erforderlich und redirect_uri darf nicht vorhanden sein, sonst gibt die Wallet invalid_request zurück.^[1] Die moldauische EVO Wallet dokumentiert zum Beispiel OpenID4VP 1.0 mit direct_post.jwt in einem Same-Device-Ablauf, ISO/IEC 18013-5 mdoc, profiliert nach OpenID4VC HAIP 1.0, sowie eine IETF Token Status List für den Widerruf.^[11]

Same-Device, Cross-Device und die Digital Credentials API

Das ARF nennt die unterstützten Remote-Kombinationen: OpenID4VP kombiniert mit einem Übertragungsmechanismus auf Basis von Weiterleitungen und benutzerdefinierten URI-Schemata; OpenID4VP oder ISO/IEC 18013-7 kombiniert mit der W3C Digital Credentials API; und optional ISO/IEC 18013-7 mit Weiterleitungen und benutzerdefinierten URI-Schemata.^[3]

Drei Wege, auf denen eine Wallet eine OpenID4VP-Anfrage empfängt.^[3][1][10]

Das ARF bezeichnet benutzerdefinierte URI-Schemata als „nicht empfohlen für Cross-Device-Abläufe“ und nennt die Digital Credentials API als Alternative.^[3] Über die API erfährt die Wallet den vom Browser authentifizierten Origin des Verifiers, „was für die Phishing-Resistenz wichtig ist“.^[1] Die W3C-Spezifikation ist noch ein Entwurf.^[9] Was der Nutzer auf dem Smartphone sieht:

Eine SD-JWT VC-Präsentation Schritt für Schritt prüfen

Eine SD-JWT VC-Präsentation enthält das vom Aussteller signierte JWT, die vom Nutzer offengelegten Disclosures und ein Key Binding JWT. Der Verifier „MUSS jede einzelne Verifiable Presentation validieren“ und jede Präsentation mit falscher Nonce ablehnen.^[1]

Die Prüfungen des Verifiers bei einer SD-JWT VC-Präsentation.^[1][3]

Signatur des Ausstellers. Das ARF führt sie als erste der Prüfungen des vertrauenden Beteiligten auf. Vertrauensanker stammen aus Trusted Lists (ETSI TS 119 612) und Lists of Trusted Entities (ETSI TS 119 602).^[3]

Disclosures. Die signierte Nutzlast enthält ein _sd-Array mit Digests; jede Disclosure besteht aus einem Salt, einem Claim-Namen und einem Wert, etwa ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"].^[1] Bilden Sie für jede Disclosure den Hash und suchen Sie den passenden Digest. Gibt es keinen Treffer, hat der Aussteller sie nicht signiert.

Key Binding JWT. Wenn Holder Binding verlangt ist, „MUSS die Wallet ein SD-JWT mit einem Key Binding JWT zurückgeben“. Sein nonce muss der Nonce Ihrer Anfrage entsprechen und sein aud Ihrem Client Identifier oder, über die Digital Credentials API, Ihrem Origin mit dem Präfix origin:.^[1] Das Beispiel aus der Spezifikation:

{ "nonce": "n-0S6_WzA2Mj", "aud": "x509_san_dns:client.example.org", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4" }

Widerruf. Der vertrauende Beteiligte prüft, dass der Anbieter „die PID oder Attestierung nicht widerrufen hat“.^[3] Die EVO Wallet aus Moldau etwa dokumentiert dafür eine IETF Token Status List.^[11]

mdoc-Präsentationen über ISO/IEC 18013-7 im Überblick

Bei einem mdoc enthält das VP Token eine base64url-kodierte DeviceResponse nach ISO/IEC 18013-5, die „eine Signatur oder einen MAC über das SessionTranscript enthält“, einschließlich einer OpenID4VP-Handover-Struktur.^[1] Dieser Handover bindet das mdoc an Ihre Anfrage, so wie Nonce und Audience ein SD-JWT VC binden.

Unser Vergleich SD-JWT VC vs. mdoc zeigt, wann welches Format passt.

Was das HAIP-Profil für EUDI-Verifier ergänzt

Das High Assurance Interoperability Profile (HAIP) schränkt die Optionen von OpenID4VP ein. Das ARF schreibt es bereits für die Ausstellung vor und erklärt, seine Verwendung „ist notwendig, um Interoperabilität sicherzustellen“.^[3] Für die Präsentation legt CIR 2026/1731 ein „OpenID4VC-HAIP-Profil“ und ein „ISO/IEC-mdoc-Profil“ fest.^[5]

Das Registrierungszertifikat „beschreibt die beabsichtigte Verwendung des vertrauenden Beteiligten und gibt die Attribute an“, die er registriert hat, und die Registrierungsverordnung gilt ab dem 24. Dezember 2026.^[6] Das Datum 11. August 2028 betrifft nur die Prüfung dieses Zertifikats durch die Wallet, nicht die Registrierung.^[5] Deutschland fasst es so zusammen: Eine Organisation „erhält ein Zugangs- und Registrierungszertifikat für die Organisation und den Anwendungsfall“.^[12] Unser Leitfaden zu vertrauenden Beteiligten der EUDI-Wallet behandelt die Registrierung ausführlich.

Häufige Fehler beim Aufbau eines OpenID4VP-Verifiers

Die Wallet ist zudem freiwillig: Der Zugang darf für Personen, die sie nicht nutzen, „in keiner Weise eingeschränkt oder benachteiligt werden“. Ihr Verifier steht daher neben einem anderen Weg.^[4]

Testressourcen

Beginnen Sie mit Referenzsoftware und Konformitätstests, bevor Sie gegen nationale Wallets testen.

• Führen Sie die Konformitätstests unter conformance.eudi.dev durch.^[3]
• Lesen Sie die Dokumentation der Referenzimplementierung unter docs.eudi.dev. Sie ist Dokumentation, keine Tests.^[3]
• Sehen Sie sich den Demo-Verifier der Nationalbank Moldaus und dessen Quellcode an.^[13]
• Prüfen Sie den Entwurf der Digital Credentials API, bevor Sie sich auf den Weg über den Browser verlassen.^[9]

Die Termine hinter Ihrem Testplan finden Sie unter Fristen der EUDI-Wallet für 2026 und 2027.

Wie Didit bei der Verifizierung mit der EUDI-Wallet hilft

Die Akzeptanz der EUDI-Wallet kommt in Kürze zu Didit: Sie steht auf unserer Roadmap, abgestimmt auf den Zeitplan der EUDI-Wallet, im selben Workflow, den Sie heute nutzen. Bis dahin können Sie Personen bereits jetzt aus der Ferne verifizieren.

• 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.
• Hat eine Person keine eID, wechselt der Ablauf zur Dokumentenprüfung mit Auslesen des NFC-Chips, Lebenderkennung und Gesichtsabgleich, pro Land konfiguriert. Eine vollständige KYC-Prüfung kostet $0.33.
• Das AML-Screening läuft im selben Ablauf für $0.20.

Ihre Pflichten als vertrauender Beteiligter bleiben bei Ihnen. Die Wallet-Dokumentation zeigt, wie eIDs pro Land aktiviert werden.

Häufig gestellte Fragen

Quellen

1. OpenID for Verifiable Presentations 1.0, OpenID Foundation, finale Spezifikation.
2. OpenID for Verifiable Presentations 1.0: finale Spezifikation verabschiedet, OpenID Foundation, 10. Juli 2025.
3. Architecture and Reference Framework v3.0.0, eu-digital-identity-wallet auf GitHub, Release vom 23. Juli 2026.
4. Verordnung (EU) 2024/1183 (eIDAS 2), EUR-Lex, Amtsblatt vom 30. April 2024.
5. Durchführungsverordnung (EU) 2026/1731 der Kommission, EUR-Lex, Amtsblatt vom 22. Juli 2026.
6. Durchführungsverordnung (EU) 2025/848 der Kommission über die Registrierung vertrauender Beteiligter von Wallets, EUR-Lex, Amtsblatt vom 7. Mai 2025.
7. Durchführungsverordnung (EU) 2024/2977 der Kommission über Personenidentifizierungsdaten, EUR-Lex, Amtsblatt vom 4. Dezember 2024.
8. ISO/IEC 18013-7, ISO-Standardseite.
9. Digital Credentials, W3C-Entwurf.
10. Digital Credentials API ausgeliefert, Chrome for Developers.
11. Entwicklerleitfaden zur EVO Wallet, Regierung der Republik Moldau, egov4dev.
12. FAQ zur EUDI-Wallet, eudi-wallet.gov.de.
13. BNM-Demo-Verifier, Regierung der Republik Moldau, egov4dev.

OpenID4VP ist der Teil der EUDI-Wallet, mit dem Entwickler am meisten arbeiten, und es ist stabil genug, um darauf aufzubauen. Wie Didit die Akzeptanz von Wallets angeht, lesen Sie auf der Lösungsseite zur EUDI-Wallet. Das Gesamtbild finden Sie in unserem Überblick zu eIDAS 2.