OpenID4VP verstehen: das Protokoll hinter den EU Digital Identity Wallets

Was ist OpenID4VP?

OpenID for Verifiable Presentations (OpenID4VP) ist das Protokoll, das es EU Digital Identity Wallets ermöglicht, verifizierte Identitätsattribute mit Unternehmen zu teilen, den sogenannten Relying Parties. Es bildet das technische Rückgrat des eIDAS-2.0-Identitätsflows.

Wenn ein Nutzer im Checkout einen QR-Code scannt und sein Wallet zurückmeldet "diese Person ist über 18", dann läuft dieser Austausch über OpenID4VP.

Der Verifizierungsablauf

Der OpenID4VP-Flow umfasst vier Akteure:

1. Issuer: die staatliche oder vertrauenswürdige Stelle, die das Credential ausgestellt hat (z. B. der österreichische Staat für einen Identitätsnachweis)
2. Holder: die Bürgerin oder der Bürger mit dem EUDI Wallet auf dem Smartphone
3. Verifier (Relying Party): das Unternehmen, das die Verifikation anfordert (Ihr Shop, Ihr KYC-System usw.)
4. Trust Framework: die EU Trusted Lists, die festlegen, welche Aussteller und Verifier legitim sind

Der Ablauf Schritt für Schritt

1. Der Verifier erstellt eine Authorization Request
   ↓
2. Die Anfrage wird in einen QR-Code (oder Deep Link) codiert
   ↓
3. Der Holder scannt den QR-Code mit dem EUDI Wallet
   ↓
4. Das Wallet interpretiert die Anfrage und zeigt an, was angefordert wird
   ↓
5. Der Holder prüft und bestätigt mit Biometrie/PIN
   ↓
6. Das Wallet erzeugt eine Verifiable Presentation (VP)
   ↓
7. Die VP wird an den Response-Endpunkt des Verifiers gesendet
   ↓
8. Der Verifier validiert die VP kryptografisch
   ↓
9. Die verifizierten Attribute werden extrahiert und verwendet

Zwei Credential-Formate

EUDI Wallets unterstützen zwei Credential-Formate, jeweils mit eigenem kryptografischem Prüfpfad:

SD-JWT VC (Selective Disclosure JWT)

Wird für Remote-Verifikationsflüsse verwendet (online, geräteübergreifend). Das Credential ist ein JSON Web Token mit selektiver Offenlegung.

• Format: JSON-basiert
• Selective Disclosure: hashbasiertes Salting; der Aussteller signiert alle Claims, der Holder kann aber nur einzelne offenlegen
• Signatur: JWS (JSON Web Signature) mit ES256
• Verifikation: JWT parsen -> Disclosures rekonstruieren -> Hashes prüfen -> Signatur validieren -> Vertrauenskette des Ausstellers prüfen

Header.Payload.Signature~Disclosure1~Disclosure2~KeyBindingJWT

mdoc / mDL (Mobile Document)

Wird für Proximity-Flows verwendet (vor Ort, NFC, BLE). Es basiert auf ISO 18013-5.

• Format: CBOR-basiert (binär)
• Selective Disclosure: in die Datenstruktur eingebaut, mit Namespaces und Datenelementen
• Signatur: COSE (CBOR Object Signing and Encryption)
• Verifikation: CBOR dekodieren -> COSE-Signatur prüfen -> Geräteauthentisierung validieren -> Zertifikatskette des Ausstellers prüfen

Beide Formate erreichen das gleiche Ziel: kryptografisch nachweisen, dass ein vertrauenswürdiger Aussteller bestimmte Aussagen über den Holder attestiert hat, allerdings über grundlegend unterschiedliche technische Wege.

WRPAC: das Zertifikat des Verifiers

Um eine Verifikationsanfrage stellen zu können, benötigt die Relying Party ein WRPAC (Wallet Relying Party Access Certificate). Dieses Zertifikat, definiert in ETSI TS 119 475:

• identifiziert die Relying Party gegenüber dem Wallet
• legt fest, welche Attribute die RP anfordern darf
• wird von einem qualifizierten Vertrauensdiensteanbieter ausgestellt
• muss gegen die EU Trusted Lists validiert werden

Das Wallet prüft das WRPAC, bevor es den Consent-Screen anzeigt. Ist das Zertifikat ungültig, abgelaufen oder nicht in der Trust List enthalten, verweigert das Wallet die Anfrage.

EU Trusted Lists

Die EU betreibt eine hierarchische Vertrauensinfrastruktur:

EU List of Trusted Lists (LOTL)
  └── Country Trusted List (z. B. Luxembourg)
       └── Trust Service Provider (z. B. LuxTrust)
            └── Trust Service (z. B. WRPAC-Ausstellung)
                 └── Certificate (Ihr WRPAC)

Das SDK muss diese Hierarchie durchlaufen, um zu validieren, dass ein WRPAC-Zertifikat von einem legitimen Anbieter in einem anerkannten Mitgliedstaat ausgestellt wurde. Das ist einer der komplexesten Teile der Implementierung: Das Trust-List-Format (XML/JSON) hat eigene Parsing-Anforderungen, und jede Mitgliedstaatenliste wird unabhängig aktualisiert.

Privacy by design

OpenID4VP setzt Datenschutz auf Protokollebene durch:

• Selective Disclosure: Der Holder wählt exakt aus, welche Attribute geteilt werden. Eine Anfrage nach age_over_18 offenbart nicht das Geburtsdatum.
• Keine Korrelation: Jede Verifizierungssitzung nutzt frisches kryptografisches Material, sodass Verifier Sitzungen nicht miteinander verknüpfen können.
• Einwilligung des Holders: Jede Attributanfrage verlangt eine explizite Zustimmung auf dem Gerät.
• Datenminimierung: Das Protokoll fördert die Beschränkung auf das Notwendige. Das Wallet macht Over-Requesting für Nutzer sichtbar.

Das unterscheidet sich grundlegend vom klassischen KYC, bei dem Unternehmen häufig mehr Daten erhalten und speichern, als sie tatsächlich brauchen.

Wie OpenEUDI das umsetzt

Das OpenEUDI SDK abstrahiert die Protokollkomplexität hinter einer sauberen API:

import { createVerifier } from '@openeudi/core';

const verifier = createVerifier({
  mode: 'production',
  wrpac: {
    certificate: process.env.WRPAC_CERT,
    privateKey: process.env.WRPAC_KEY,
  },
  trustList: {
    lotlUrl: 'https://ec.europa.eu/tools/lotl/eu-lotl.xml',
    refreshInterval: 86400, // 24 Stunden
  },
});

Intern erledigt das SDK:

1. Aufbau einer spezifikationskonformen Authorization Request
2. Kodierung in einen QR-Code mit konfigurierbarem Styling
3. Einrichtung eines Response-Endpunkts für die VP des Wallets
4. Validierung der VP mit dem passenden Format-Handler (SD-JWT oder mdoc)
5. Prüfung des Ausstellerzertifikats gegen die EU Trusted Lists
6. Extraktion und Rückgabe ausschließlich der angeforderten Attribute
7. Bereinigung kryptografischen Materials aus dem Speicher

All das steckt hinter verifier.createSession() und session.onVerified().

Grenzüberschreitende Compliance

Jeder EU-Mitgliedstaat hat einen gewissen Ermessensspielraum, welche Attribute wann und unter welchen Bedingungen angefragt werden dürfen. Zum Beispiel:

• Altersgrenzen unterscheiden sich nach Produktkategorie und Land
• einige Länder beschränken bestimmte Attributfreigaben
• nationale Wallet-Implementierungen nutzen unterschiedliche Credential-Schemata

OpenEUDI enthält ein maschinenlesbares Compliance-Mapping (JSON) für alle 27 Mitgliedstaaten, sodass Entwickler vor einer Anfrage die Verfügbarkeit der Attribute prüfen können.

Wie es mit dem Protokoll weitergeht

Die OpenID4VP-Spezifikation entwickelt sich in der Arbeitsgruppe der OpenID Foundation weiter. Aktive Themen sind unter anderem:

• Presentation Exchange 2.0: flexiblere Möglichkeiten, akzeptable Credentials zu beschreiben
• Status Assertions: Echtzeitprüfung auf Widerruf von Credentials
• Verbesserte Cross-Device-Flows: bessere UX für Verifikation von Mobile zu Desktop
• Batch Verification: Prüfung mehrerer Credentials in einem einzigen Ablauf

OpenEUDI wird diese Änderungen mit einem versionierten Protocol-Adapter-Muster nachziehen. So bleibt die öffentliche API stabil, während interne Handler an neue Spezifikationsstände angepasst werden.

---

OpenEUDI implementiert OpenID4VP für das EUDI-Wallet-Ökosystem. Das SDK ist MIT-lizenziert und kostenlos nutzbar. Für Produktionsdeployments mit verwalteten WRPAC-Zertifikaten sehen Sie sich die Managed Plans von eIDAS Pro an.

Verwandte Artikel

OpenEUDI SDK Quickstart: Ihre erste Verifizierung in 5 Minuten

Eine Schritt-für-Schritt-Anleitung, um das OpenEUDI SDK zu installieren, eine Verifizierungssitzung zu erstellen und das Ergebnis zu verarbeiten - alles in weniger als 5 Minuten im DEMO-Modus.

6 Min. Lesezeit

Wie die eIDAS-Verifizierung funktioniert: eine technische Tiefenanalyse

Eine umfassende technische Aufschlüsselung des eIDAS-Verifizierungsablaufs – von der QR-Code-Erzeugung bis zur Attributvalidierung, inklusive Protokollen, Sicherheitsmaßnahmen und Integrationsmustern.

12 Min. Lesezeit