Understanding OpenID4VP: The Protocol Behind EU Digital Identity Wallets

What is OpenID4VP?

OpenID for Verifiable Presentations (OpenID4VP) is the protocol that enables EU Digital Identity Wallets to share verified identity attributes with businesses (called Relying Parties). It's the technical backbone of the eIDAS 2.0 identity verification flow.

When a user scans a QR code at checkout and their wallet sends back "this person is over 18" — that exchange happens over OpenID4VP.

The Verification Flow

The OpenID4VP flow has four actors:

1. Issuer — The government or trusted authority that issued the credential (e.g., Austrian government issuing a national ID)
2. Holder — The citizen with the EUDI Wallet on their phone
3. Verifier (Relying Party) — The business requesting verification (your e-commerce store, KYC system, etc.)
4. Trust Framework — EU Trusted Lists that establish which issuers and verifiers are legitimate

Step-by-Step Flow

1. Verifier creates an Authorization Request
   ↓
2. Request is encoded into a QR code (or deep link)
   ↓
3. Holder scans QR code with EUDI Wallet
   ↓
4. Wallet parses the request and shows what's being asked
   ↓
5. Holder reviews and approves with biometrics/PIN
   ↓
6. Wallet creates a Verifiable Presentation (VP)
   ↓
7. VP is sent to the Verifier's response endpoint
   ↓
8. Verifier validates the VP cryptographically
   ↓
9. Verified attributes are extracted and used

Two Credential Formats

EUDI Wallets support two credential formats, each with different cryptographic verification paths:

SD-JWT VC (Selective Disclosure JWT)

Used for remote verification flows (online, cross-device). The credential is a JSON Web Token with selective disclosure capabilities.

• Format: JSON-based
• Selective Disclosure: Hash-based salting — the issuer signs all claims, but the holder can reveal only specific ones
• Signature: JWS (JSON Web Signature) with ES256
• Verification: Parse JWT → reconstruct disclosures → verify hashes → validate signature → check issuer trust chain

Header.Payload.Signature~Disclosure1~Disclosure2~KeyBindingJWT

mdoc / mDL (Mobile Document)

Used for proximity verification flows (in-person, NFC, BLE). Based on ISO 18013-5.

• Format: CBOR-based (binary)
• Selective Disclosure: Built into the data structure — namespaces and data elements
• Signature: COSE (CBOR Object Signing and Encryption)
• Verification: Decode CBOR → verify COSE signature → validate device authentication → check issuer certificate chain

Both formats achieve the same goal — cryptographically proving that a trusted issuer attested to specific claims about the holder — but through fundamentally different technical paths.

WRPAC: The Verifier's Certificate

To make a verification request, the Relying Party needs a WRPAC (Wallet Relying Party Access Certificate). This certificate, defined in ETSI TS 119 475:

• Identifies the Relying Party to the wallet
• Specifies which attributes the RP is authorized to request
• Is issued by a qualified trust service provider
• Must be validated against EU Trusted Lists

The wallet checks the WRPAC before showing the consent screen. If the certificate is invalid, expired, or not in the trust list, the wallet refuses the request.

EU Trusted Lists

The EU maintains a hierarchical trust infrastructure:

EU List of Trusted Lists (LOTL)
  └── Country Trusted List (e.g., Luxembourg)
       └── Trust Service Provider (e.g., LuxTrust)
            └── Trust Service (e.g., WRPAC issuance)
                 └── Certificate (your WRPAC)

The SDK must traverse this hierarchy to validate that a WRPAC certificate was issued by a legitimate provider in a recognized member state. This is one of the most complex parts of the implementation — the trust list format (XML/JSON) has its own parsing requirements, and lists are updated independently by each member state.

Privacy by Design

OpenID4VP enforces privacy at the protocol level:

• Selective Disclosure: The holder chooses exactly which attributes to share. Asking for "age_over_18" does not reveal the birth date.
• No Correlation: Each verification session uses fresh cryptographic material, preventing verifiers from linking sessions.
• Holder Consent: Every attribute request requires explicit user approval on the device.
• Data Minimization: The protocol encourages requesting only what's needed. The wallet UI makes over-requesting visible to users.

This is fundamentally different from traditional KYC, where businesses often receive (and store) more data than necessary.

How OpenEUDI Implements This

The OpenEUDI SDK abstracts the protocol complexity behind a clean 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 hours
  },
});

Internally, the SDK:

1. Constructs a spec-compliant Authorization Request
2. Encodes it into a QR code (with configurable styling)
3. Sets up a response endpoint for the wallet's VP
4. Validates the VP using the appropriate format handler (SD-JWT or mdoc)
5. Checks the issuer's certificate against EU Trusted Lists
6. Extracts and returns only the requested attributes
7. Cleans up cryptographic material from memory

All of this happens behind verifier.createSession() and session.onVerified().

Cross-Country Compliance

Each EU member state has some discretion over which attributes can be requested and under which conditions. For example:

• Age verification thresholds vary by product category and country
• Some countries restrict certain attribute disclosures
• National wallet implementations may use different credential schemas

OpenEUDI includes a machine-readable compliance mapping (JSON) for all 27 member states, so developers can check attribute availability before making requests.

What's Next for the Protocol

The OpenID4VP specification is still evolving through the OpenID Foundation working group. Key areas of active development:

• Presentation Exchange 2.0 — more flexible ways to specify which credentials are acceptable
• Status assertions — real-time credential revocation checking
• Cross-device flow improvements — better UX for mobile-to-desktop verification
• Batch verification — verifying multiple credentials in a single flow

OpenEUDI will track these changes with a versioned protocol adapter pattern, keeping the public API stable while internal handlers are updated per spec revision.

---

OpenEUDI implements OpenID4VP for the EUDI Wallet ecosystem. The SDK is MIT-licensed and free to use. For production deployments with managed WRPAC certificates, see eIDAS Pro's managed plans.

Related Articles

OpenEUDI SDK Quickstart: Your First Verification in 5 Minutes

A step-by-step tutorial to install the OpenEUDI SDK, create a verification session, and handle the result — all in under 5 minutes using DEMO mode.

6 min read

How eIDAS Verification Works: A Technical Deep Dive

A comprehensive technical breakdown of the eIDAS verification flow, from QR code generation to attribute validation, covering protocols, security measures, and integration patterns.

12 min read