What the EUDI Wallet Actually Is, Technically

When people hear “digital identity wallet,” they often picture a phone app that stores a digital version of an ID card. That picture is not wrong, but it misses the engineering point.

The European Digital Identity Wallet (EUDI Wallet) is better understood as a trust architecture implemented through a wallet. It defines how digitally signed credentials are issued to a person, kept under that person’s control, presented to a service, and verified with evidence that the data is authentic, current, and being used by its legitimate holder.

The app is only one component. The system is the interesting part.

A wallet is a participant in a credential ecosystem

The EUDI model has three primary roles:

• An issuer creates a credential and signs the claims it contains.
• A holder keeps that credential in a wallet and decides when to present it.
• A verifier, sometimes called a relying party, requests specific evidence and validates the response.

A credential can represent Person Identification Data (PID), an electronic attestation of attributes, a qualified attestation, or a mobile driving licence. The point is not to put every fact about a person into a single account. The point is to let an authoritative issuer make a signed statement and let the holder present only the evidence a verifier actually needs.

That is a different model from a conventional identity provider. In a typical sign-in flow, an application redirects a user to an account provider, which tells the application who the user is. In a wallet flow, the verifier asks for a credential or a small set of claims; the wallet mediates the user’s consent and returns a cryptographically verifiable presentation.

The two protocol directions

Two OpenID-family protocols describe the core movement of credentials.

OpenID for Verifiable Credential Issuance (OID4VCI) covers the trip from issuer to wallet. The wallet discovers issuer metadata, obtains authorization when necessary, and requests a credential with a cryptographic proof. The protocol supports both user-initiated authorization-code flows and issuer-initiated pre-authorized flows, where a credential offer can begin the journey.

OpenID for Verifiable Presentations (OID4VP) covers the trip from wallet to verifier. A verifier sends an authorization request describing the credential evidence it needs. The wallet asks the holder for approval, selects matching credentials, and returns a presentation. In the final OID4VP 1.0 model, the verifier expresses requests for verified credentials through DCQL, the Digital Credentials Query Language.

This split is useful because issuance and presentation have different security questions. Issuance asks whether an issuer may create a credential for a wallet and which key should be associated with it. Presentation asks whether the requested evidence is authentic, appropriate for this transaction, and disclosed to the intended verifier.

Credentials are signed data, not screenshots

At the center is the verifiable credential: claims about a subject plus metadata and a cryptographic proof from an issuer. The verifier does not have to trust the visual design of a card. It validates a signature and the issuer’s trust chain.

The EUDI technical framework uses two important representations for PID credentials:

• SD-JWT, a JWT-based format that supports selective disclosure.
• mdoc, an ISO/IEC 18013-5 format originally designed for mobile driving licences and suited to compact, device-to-device exchanges.

The representations differ, but they implement the same essential property: a holder can reveal a subset of signed attributes without making the full credential available by default.

With SD-JWT, the issuer commits to attribute values through hashes. At presentation time, the holder supplies only the disclosures needed for that request. With mdoc, the issuer signs a Mobile Security Object that includes digests of data elements; the wallet can return the selected elements while the verifier checks them against the signed object.

Selective disclosure changes the product question from “Can this app see the user’s identity document?” to “Which verified facts are necessary for this transaction?” That is a much better boundary for privacy-sensitive services.

The wallet must prove it is not merely forwarding a file

A signed credential alone is not enough. If a credential could be copied and replayed, it would behave like a transferable document.

EUDI flows therefore use holder binding: the credential is associated with a key controlled by the holder’s wallet. During a presentation, the wallet proves possession of the corresponding private key. In an SD-JWT flow, that proof is commonly expressed as a key-binding JWT. It incorporates a fresh nonce from the verifier and the verifier’s client identifier, so a response is tied to the current session and intended recipient.

For mdoc, the equivalent idea is device authentication. The wallet signs the response with the device key associated with the credential. The verifier checks that signature as part of its validation work.

This is the difference between verifying a document and verifying a live presentation of that document. The verifier receives evidence not only that an issuer signed the claims, but also that the responding wallet controls the key bound to them.

Trust is a stack of checks

A production verifier does more than parse a token. Its validation stack typically includes:

1. Issuer trust: Is the issuer signature valid, and does its certificate chain lead to a trusted authority?
2. Data integrity: Do the disclosed attributes match the issuer-signed commitments?
3. Holder binding: Did the wallet prove control of the expected key for this session?
4. Validity and status: Is the credential within its validity period, and is status or revocation information acceptable?
5. Request binding: Is the response tied to this verifier and this transaction rather than reusable elsewhere?

The Architecture and Reference Framework (ARF) sets the interoperability direction for this ecosystem: OpenID protocols for issuance and presentation, established cryptographic formats such as JOSE and COSE, and credential formats including SD-JWT and mdoc. Member-state implementations can differ, but interoperability depends on this shared technical vocabulary.

What an integration team should take away

The EUDI Wallet is not a new database of identities that every service must query. It is a mechanism for exchanging verifiable evidence with user participation.

For builders, that changes the design work. The crucial questions are not only how to launch a wallet request, but also:

• Which attributes are genuinely required for the service?
• Which issuer and trust anchors are acceptable?
• Which credential formats and presentation channels must be supported?
• How will the verifier validate signatures, holder binding, validity, and status?
• How will the service explain the request clearly enough for a person to give meaningful consent?

The wallet is the user-facing surface of those decisions. Technically, it is a protocol participant, key holder, consent boundary, and presentation engine inside a wider trust framework.

That is why treating it as “an ID card on a phone” is too small a model. The EUDI Wallet is infrastructure for asking for less data while obtaining stronger evidence.