eIDAS 2.0 uses OpenID for Verifiable Presentations (OpenID4VP) as the standard protocol for presenting credentials stored in the EUDI Wallet to relying parties. In simple terms, OpenID4VP defines how a wallet holder shares specific credential data with a verifier in a secure, privacy-respecting way. The sections below walk through how this works in practice, what organizations need to know, and how to prepare for implementation.
What role does OpenID4VP play in the EUDI Wallet architecture?
OpenID4VP is the presentation layer of the EUDI Wallet ecosystem. It is the protocol that governs how a wallet holder responds to a request for credential data, allowing them to share specific attributes from their digital identity wallet with a verifier such as a bank, government portal, or healthcare provider. Without OpenID4VP, there would be no standardized way for wallets and verifiers to communicate credential presentations across borders and sectors.
Within the broader EUDI Wallet architecture, OpenID4VP sits alongside other components like the Architecture and Reference Framework (ARF), trust registries, and the credential issuance layer. It acts as the bridge between the wallet and the relying party, ensuring that presentations happen in a consistent, interoperable way regardless of which Member State issued the wallet or which sector the verifier operates in.
This is particularly important under eIDAS 2.0, which requires that EU Member States issue wallets that work across borders and across both public and private sector services. OpenID4VP makes that cross-border, cross-sector interoperability technically achievable. Organizations in financial services and other regulated industries are already looking at how this protocol fits into their existing verification flows.
How does the OpenID4VP credential presentation flow work?
The OpenID4VP credential presentation flow works in four main steps: the verifier sends a presentation request to the wallet, the wallet holder reviews and approves what to share, the wallet generates a verifiable presentation containing only the requested attributes, and the verifier receives and validates the presentation. This flow ensures that the user remains in control of what data leaves their wallet at every step.
Here is a more detailed breakdown of how the flow progresses:
- Presentation request: The verifier (also called the relying party) sends an Authorization Request to the wallet. This request specifies which credentials or attributes are needed, using a format called a Presentation Definition.
- User consent: The wallet app presents the request to the holder, who reviews what is being asked and explicitly approves the disclosure. The holder can choose to share only what is necessary.
- Presentation generation: The wallet creates a Verifiable Presentation containing the approved attributes, cryptographically signed to prove authenticity and integrity.
- Response and validation: The wallet sends the presentation back to the verifier via a secure redirect or direct post endpoint. The verifier then validates the cryptographic proof and checks the credential against the relevant trust registry.
This flow reflects the selective disclosure principle that is central to eIDAS 2.0 and the EUDI Wallet design. A user proving they are over 18 does not need to share their full date of birth, their address, or any other personal data. Only the minimum necessary information leaves the wallet.
What is the difference between OpenID4VP and OpenID4VCI?
OpenID4VP and OpenID4VCI address two different sides of the credential lifecycle. OpenID4VCI (OpenID for Verifiable Credential Issuance) handles how credentials are issued to a wallet, while OpenID4VP handles how those credentials are later presented to a verifier. Together, they form the core protocol pair for the EUDI Wallet ecosystem, but they serve opposite directions of data flow.
Think of it this way: OpenID4VCI is used when your government issues a digital driving license to your wallet. OpenID4VP is used when you later present that license to a car rental company to prove you are qualified to drive. The issuance protocol and the presentation protocol are designed to work together but operate independently.
For organizations preparing for eIDAS 2.0 compliance, the distinction matters because the two protocols require different technical integrations. A credential issuer such as a national authority or a bank needs to implement OpenID4VCI. A relying party that wants to accept and verify credentials needs to implement OpenID4VP. Many organizations will need to implement both, depending on their role in the ecosystem. Understanding this split early helps teams plan their technical roadmap more accurately.
How does OpenID4VP handle trust and verifier authentication?
OpenID4VP handles trust by requiring verifiers to authenticate themselves before a wallet will respond to a presentation request. Under eIDAS 2.0, verifiers must be registered in a trust registry and present a signed request that the wallet can validate against that registry. This means the wallet holder can see who is asking for their data and confirm that the verifier is a legitimate, recognized entity before sharing anything.
This verifier authentication step is one of the most important privacy and security features of the OpenID4VP design. In practice, a verifier publishes its metadata, including its public key and the types of credentials it is authorized to request, in a way that wallets can discover and verify. When a presentation request arrives, the wallet checks the verifier’s identity against the trust chain before even prompting the user.
Under the eIDAS 2.0 framework, this trust chain connects to the national and European trust infrastructure. Verifiers operating in regulated sectors such as healthcare or government services must meet specific registration and authorization requirements before they can request sensitive credential attributes. This gives both users and regulators confidence that credential presentations cannot be requested by unauthorized parties.
Which credential formats does OpenID4VP support under eIDAS 2.0?
Under eIDAS 2.0, OpenID4VP supports two primary credential formats: ISO/IEC 18013-5 mdoc (used for mobile documents such as the mobile driving license) and SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credentials). Both formats are included in the EUDI Wallet Architecture and Reference Framework and are being tested across the large-scale pilot programs that ran through 2025 and into 2026.
The two formats serve slightly different purposes and contexts:
- mdoc (ISO 18013-5): Originally developed for mobile driving licenses, this format is well suited for proximity-based presentations such as showing your ID at a physical location using Bluetooth or NFC. It is highly structured and widely supported in identity document use cases.
- SD-JWT VC: A JSON-based format designed for online credential presentations. It supports selective disclosure natively, meaning the holder can reveal individual attributes without exposing the full credential. This format is particularly relevant for digital onboarding, authentication, and data sharing in online services.
Both formats are cryptographically signed, ensuring that the credential data cannot be tampered with between issuance and presentation. The choice of format often depends on the use case: proximity interactions tend to favor mdoc, while online and cross-border digital services lean toward SD-JWT VC. Organizations implementing OpenID4VP should assess which format or combination of formats aligns with their specific verification scenarios.
What do organizations need to implement OpenID4VP for eIDAS 2.0 compliance?
To implement OpenID4VP for eIDAS 2.0 compliance, organizations need three foundational elements: technical integration with the OpenID4VP protocol, registration within the relevant trust framework, and alignment with the credential formats and presentation definitions required by their sector. The exact requirements depend on whether the organization acts as a verifier, an issuer, or both within the EUDI Wallet ecosystem.
From a technical perspective, verifiers need to build or integrate an OpenID4VP-compatible verification endpoint, implement support for the relevant credential formats (mdoc and/or SD-JWT VC), and ensure their systems can validate cryptographic proofs and check trust registries. This typically involves working with identity platform providers or open-source toolkits aligned with the ARF specifications.
From a compliance and governance perspective, organizations must register as recognized verifiers under the applicable national or European trust framework, define the minimum data they need to request (in line with data minimization principles under GDPR and eIDAS 2.0), and maintain audit trails of credential presentations. Sectors such as government services and finance have additional sector-specific requirements that layer on top of the baseline eIDAS 2.0 obligations.
Organizations that are still in the early stages of assessing their readiness should start by mapping their current identity verification flows against the OpenID4VP model, identifying gaps in technical infrastructure, and engaging with the relevant trust framework administrators in their Member State. The resources available on digital identity standards and EUDI Wallet specifications can help teams build a clearer picture of what implementation actually involves.
How TrustTech helps with OpenID4VP and eIDAS 2.0 implementation
Implementing OpenID4VP and preparing for eIDAS 2.0 compliance involves navigating technical specifications, trust framework requirements, and sector-specific obligations all at once. TrustTech helps organizations work through this complexity in a structured, practical way.
Specifically, TrustTech supports organizations with:
- Technical integration: Building OpenID4VP-compatible verification and issuance flows that align with the EUDI Wallet Architecture and Reference Framework
- Credential format support: Implementing both mdoc and SD-JWT VC formats for the use cases that matter most to your organization
- Trust framework alignment: Registering as a recognized verifier and connecting to the relevant national and European trust infrastructure
- Compliance readiness: Mapping your current identity processes to eIDAS 2.0 requirements and identifying the gaps that need to be addressed
- Cross-sector expertise: Drawing on experience across finance, government, healthcare, and other regulated sectors to tailor implementation to your specific context
Whether you are just starting to assess your digital identity infrastructure or ready to move into active implementation, TrustTech brings the technical depth and regulatory knowledge to get you there. Get in touch with TrustTech to discuss how your organization can prepare for OpenID4VP and eIDAS 2.0 compliance.