What is the EUDI Wallet? A guide for relying parties
The European Digital Identity (EUDI) Wallet is a user-controlled way to hold, manage, and present personal identification data and electronic attestations of attributes to public and private services. For a relying party, integrating a wallet means requesting specific evidence, validating the presentation and its issuer, then applying the result inside the service's own policy.
The wallet is one part of the European Digital Identity Framework. It is not one EU-operated app or one universal credential format: Member States and wallet providers implement wallet units, while issuers provide credentials and relying parties decide which evidence their service accepts.
The four roles in a wallet presentation
- Issuer: creates and signs a credential, such as person identification data (PID) or another electronic attestation of attributes.
- Wallet and holder: the wallet stores credentials for its user. The user reviews a request and chooses whether to present the requested information.
- Relying party (verifier): the service requesting evidence. It identifies itself, states what data it needs and why, then validates the response under its configured trust and acceptance policy.
- Trust framework: rules, registrations, metadata, and trust anchors help the wallet and relying party establish which participants and credentials they can accept.
These roles may be operated by different organizations. A wallet does not issue every credential it contains, and a verifier should not infer that a valid signature alone makes a credential acceptable for its use case.
How a remote presentation works
The exact protocol profile depends on the wallet, credential, and deployment. A common relying-party flow has these steps:
- The service creates a transaction and requests the minimum credential claims or predicates it needs.
- The holder opens the request in a compatible wallet, reviews the request, and approves or declines it.
- The wallet sends a presentation to the verifier using the supported protocol and credential format.
- The verifier checks the issuer and credential, the holder or device proof, and that the presentation is bound to the expected verifier and transaction.
- The relying party applies its own eligibility, onboarding, or access rule to the verified result.
OpenID for Verifiable Presentations (OID4VP) is one protocol for requesting and receiving presentations. It supports different credential formats and same-device or cross-device flows. A deployment still needs a profile that defines the formats, request parameters, trust, and security requirements its wallets and verifiers share.
Credentials and formats are separate choices
For concise definitions of the roles, credential types, protocols, and formats used below, see the EUDI Wallet glossary.
A credential describes signed information from an issuer. A presentation is what the holder shares for a particular interaction. The same ecosystem can include multiple credential types and encodings; a verifier must validate the one it actually requested.
- PID carries person identification data under the applicable profile.
- Electronic attestations of attributes can express other facts from their respective issuers.
- Mobile driving licences are a document type based on the ISO mdoc ecosystem; the verifier must support the requested document type and presentation profile.
- SD-JWT VC and mdoc are distinct formats with different proof and trust processing. A wallet supporting one does not imply support for the other.
See the implementation guides for SD-JWT verification and ISO mdoc and mobile driving licence verification.
What a relying party needs to decide
Before building a request, define:
- the purpose and lawful basis for the check;
- the minimum attributes or predicate needed for that purpose;
- the accepted credential profiles, issuers, and trust sources;
- how to handle unsupported wallets, declined requests, invalid proofs, and unavailable credentials;
- what result to retain, for how long, and where to use it in the service's own decision process.
Wallet approval is a user interaction; it does not replace the relying party's responsibility to justify its request, protect received data, and follow the rules that apply to its service. Registration and acceptance duties depend on the relying party and the applicable EU and national requirements.
Build an EUDI Wallet verification flow
DLBR EID provides a relying-party API for supported wallet presentation profiles. Start with the EUDI Wallet verification API, follow the API quickstart, then review the EUDI integration checklist and OID4VP nonce and state validation.
Test with synthetic credentials in the sandbox before configuring issuer trust and production relying-party requirements. Synthetic examples are useful for integration, but they are not credentials issued by an EUDI authority.
If you are choosing an evidence path, compare EUDI Wallet presentations with document verification and review the EUDI Wallet verification API.