eIDAS 2.0 uses OpenID for Verifiable Presentations (OID4VP) as the standard protocol for presenting credentials stored in the EUDI Wallet to relying parties. In practical terms, OID4VP 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 OID4VP play in the EUDI Wallet architecture?
OID4VP 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 EUDI Wallet with a verifier such as a bank, government portal, or healthcare provider. Without OID4VP, there would be no standardized way for wallets and verifiers to communicate credential presentations across borders and sectors.
Within the broader EUDI Wallet architecture, OID4VP sits alongside other components such as the Architecture and Reference Framework (ARF), national trusted lists, 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. The ARF provides the technical elaboration of the requirements set out in the legally binding implementing acts and is not itself legislation.
This is particularly important under eIDAS 2.0, which amends Regulation (EU) 910/2014 and requires that EU Member States issue wallets that work across borders and across both public and private sector services. OID4VP makes that cross-border, cross-sector interoperability technically achievable. Organizations in financial services and other regulated industries are already assessing how this protocol fits into their existing verification flows.
How does the OID4VP credential presentation flow work?
The OID4VP 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 approval: 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, checks the revocation status of the credential, and verifies the wallet unit attestation to confirm the presenting wallet runs on a certified wallet solution.
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 OID4VP and OID4VCI?
OID4VP and OID4VCI address two different sides of the credential lifecycle. OID4VCI (OpenID for Verifiable Credential Issuance) handles how credentials are issued to a wallet, while OID4VP handles how those credentials are later presented to a verifier. Together, they form the core protocol pair for the EUDI Wallet ecosystem, and they serve opposite directions of data flow.
Think of it this way: OID4VCI is used when a government authority issues a digital driving licence to your wallet. OID4VP is used when you later present that licence 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 OID4VCI. A relying party that wants to accept and verify credentials needs to implement OID4VP. 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 OID4VP handle trust and verifier authentication?
OID4VP handles trust by requiring verifiers to authenticate themselves before a wallet will respond to a presentation request. Under eIDAS 2.0, relying parties must be registered under CIR (EU) 2025/848 with the national authority of the Member State in which they are established, and must present a signed request that the wallet can validate. 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 OID4VP design. A relying party registers per intended use, specifying which attributes and attestations it is authorized to request. When a presentation request arrives, the wallet checks the request against the registered scope before prompting the user.
Under the eIDAS 2.0 framework, this connects to the national and European trust infrastructure. Governance of this infrastructure is a shared responsibility: the European Commission sets the legal framework and adopts implementing acts, EU Member States certify and notify wallet solutions and supervise actors within their jurisdiction, national competent authorities and registrars manage registration at the national level, and qualified trust service providers underpin the cryptographic trust chain. 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 OID4VP support under eIDAS 2.0?
Under eIDAS 2.0, OID4VP supports two primary credential formats: mdoc (ISO/IEC 18013-5, used for mobile documents such as the mobile driving licence) and SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credentials). Both formats are included in the EUDI Wallet Architecture and Reference Framework and were tested across the large-scale pilot programs that ran from April 2023 through 2025.
The two formats serve slightly different purposes and contexts:
- mdoc (ISO/IEC 18013-5): Originally developed for mobile driving licences, this format is well suited for proximity-based presentations such as showing your ID at a physical location using Bluetooth or NFC. For online presentation scenarios, ISO/IEC TS 18013-7 extends the mdoc model. The format 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, making the credential data tamper-evident 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 OID4VP should assess which format or combination of formats aligns with their specific verification scenarios.
What do organizations need to implement OID4VP for eIDAS 2.0 compliance?
To implement OID4VP for eIDAS 2.0 compliance, organizations need three foundational elements: technical integration with the OID4VP 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 OID4VP-compatible verification endpoint, implement support for the relevant credential formats (mdoc and/or SD-JWT VC), and ensure their systems can perform the three distinct validation steps: verifying the issuer’s signature against the relevant national trusted list, checking the revocation status of the credential via the issuer’s status information, and validating the wallet unit attestation to confirm the presenting wallet runs on a certified wallet solution. Only the first of these checks can be completed fully offline. 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 relying parties under CIR (EU) 2025/848 with the national authority of the Member State in which they are established. Registration is per intended use: organizations declare which attributes and attestations they will request, and wallets check requests against this registered scope. Organizations must also define the minimum data they need to request in line with data minimization principles under the GDPR and eIDAS 2.0, and maintain audit trails of credential presentations. Sector-specific legislation continues to apply alongside eIDAS 2.0 obligations, and not every credential will automatically carry the same legal consequence in every Member State. Sectors such as government services and finance have additional 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 OID4VP model and identifying gaps in technical infrastructure. The legal deadline for Member States to issue wallets and for public sector bodies to accept them is 24 December 2026. For the relevant regulated private sectors, the acceptance obligation under Article 5f applies from 24 December 2027. Practical interoperability and national rollout will develop at different rates across Member States, so organizations should plan for a phased approach. The resources available on digital identity standards and EUDI Wallet specifications can help teams build a clearer picture of what implementation actually involves.
How the ID Connector supports OID4VP and eIDAS 2.0 implementation
The ID Connector is an integration that lets relying parties accept every certified European wallet, whatever Member State issued it, for identification, login and qualified signing. EUDI Wallet acceptance comes first; the same interface also carries other IDs, such as national eIDs, bank IDs and identity documents, inside and outside the EU.
In the context of OID4VP, the ID Connector handles the protocol-level integration so that organizations do not need to build and maintain that layer themselves. Specifically, it covers:
- Wallet acceptance: Accepting every notified EUDI Wallet solution regardless of the issuing Member State, in line with the interoperability requirements of eIDAS 2.0
- Trust management and verification: Verifying issuer signatures against the relevant national trusted lists, checking credential revocation status, and validating wallet unit attestations to confirm the presenting wallet runs on a certified wallet solution
- Registered attribute scope: Checking incoming presentation requests against the attributes and attestations registered under CIR (EU) 2025/848, so that only authorized data is requested
- Credential format support: Processing both mdoc and SD-JWT VC formats for the use cases that matter to your organization, whether proximity-based or online
- Qualified signing: Connecting to a qualified trust service provider for qualified electronic signatures where the use case requires it
Organizations in financial services, healthcare, pharma, and government can connect to the ID Connector to meet the OID4VP integration requirements without rebuilding their identity infrastructure from the ground up. Get in touch with TrustTech to discuss how your organization can implement OID4VP acceptance ahead of the 24 December 2026 deadline for public sector bodies and the 24 December 2027 obligation for regulated private sector relying parties.