How EUDI Wallet Architecture and Credentials Work

The EUDI Wallet is not a central identity API. It is a federated ecosystem in which certified wallets receive credentials from trusted issuers and present selected data to registered relying parties under the user's control.

That design has a simple consequence: reading the returned JSON is the easy part. Trusting it requires a complete chain from the request, through the wallet and credential, back to recognized issuers and ecosystem registers.

The core actors

The latest EUDI Architecture and Reference Framework describes a number of roles. Five are enough to understand a remote presentation:

• Wallet user: the natural or legal person using the wallet.
• Wallet provider: provides a certified wallet solution and its secure components.
• PID provider: issues Person Identification Data associated with the wallet user.
• Attestation provider: issues an EAA, QEAA or public-body attestation.
• Relying party: requests and validates attributes to provide a service.

The ecosystem also depends on national registrars, supervisory bodies, certification authorities, trust lists and authentic sources. These are not background bureaucracy: they provide the machine-verifiable answer to “who is allowed to make this claim?”

A wallet unit is more than an app

The ARF uses Wallet Unit for the configuration controlled by one user. It can include wallet app instances, secure cryptographic applications and secure cryptographic devices.

Private keys should remain protected by the wallet's secure environment. Presentations are bound to those keys so copied credential data cannot simply be replayed from another device. Wallet and key attestations help other participants reason about the wallet unit and the protection behind its keys.

This is one reason a screenshot, QR image or exported JSON object is not equivalent to a verified wallet presentation.

Issuance: how a credential enters the wallet

Before a presentation, an issuer must provision a credential.

For PID, a provider verifies the person through the relevant high-assurance identity process and associates the resulting data with the wallet. For another attribute, an attestation provider verifies its authentic source or other basis and issues the corresponding electronic attestation.

Current EUDI interoperability work uses OpenID for Verifiable Credential Issuance (OpenID4VCI) for issuance scenarios. A simplified sequence is:

1. The user starts an issuance journey with a trusted provider.
2. The wallet receives an offer or authorization context.
3. The issuer authenticates the user and checks entitlement.
4. The wallet proves control of the target key where required.
5. The issuer returns a signed credential bound to the wallet.
6. The wallet stores the credential and relevant status information.

Issuance is not universal discovery. The user must have access to the issuer and qualify for the credential.

Presentation: how a service requests data

For remote online use, OpenID for Verifiable Presentations (OpenID4VP) is the central presentation protocol in current EUDI testing.

The relying party creates a request that identifies the transaction, specifies acceptable credential formats and describes the requested attributes. The request reaches the wallet through a same-device handoff, cross-device flow or another supported transport.

The wallet then:

• authenticates the relying party;
• checks whether the requested data fits its registered purpose;
• shows the request to the user;
• obtains user approval; and
• returns a presentation bound to that request and wallet session.

The relying party validates the response and maps the verified claims into its own application session. It—not the wallet—decides whether those claims satisfy the business rule.

The Commission's Launchpad test cases explicitly exercise remote PID presentation and rejection paths involving untrusted readers and issuer roots.

Credential formats: mdoc and SD-JWT VC

EUDI does not require all credentials to use one serialization.

Two important formats are:

• ISO mdoc, derived from the mobile-document standards used by mobile driving licences; and
• SD-JWT VC, a JSON/JWT-based format designed for selective disclosure.

Both can support revealing a subset of claims, but their encoding, issuer signatures, device binding, presentation construction and validation differ. A relying party should normalize verified facts only after format-specific verification succeeds.

Format support also belongs in the coverage matrix. A wallet that can present PID as mdoc is not automatically compatible with a verifier that accepts only an SD-JWT VC profile.

PID is not every credential

Person Identification Data is the identity anchor associated with the wallet. Other facts arrive as attestations.

• A QEAA is issued by a qualified trust service provider and meets the qualified requirements in eIDAS.
• A public-body attestation comes from or on behalf of a public body responsible for an authentic source.
• Another EAA can represent a lower-assurance or non-qualified attribute.

The data may look similar at the application boundary, but the issuer authorization, trust source and legal effect can be different. “Verified credential” is not a sufficient policy category on its own.

Trust: what a verifier actually checks

A robust verifier checks several layers:

1. Request integrity: the wallet responded to the relying party's authentic request.
2. Freshness: nonce, state and expiry values prevent replay.
3. Relying-party binding: the presentation is bound to the expected origin, client or transaction context.
4. Credential signature: the issuer's cryptographic proof validates.
5. Issuer authority: the issuer is trusted for this credential type.
6. Wallet/device binding: the presenting wallet proves possession of the correct key where required.
7. Credential status: expiry, revocation or suspension rules pass.
8. Disclosure scope: returned claims match the request and permitted purpose.
9. Schema and semantics: claim names, namespace, country and credential profile mean what the application thinks they mean.
10. Application binding: the result belongs to the correct user journey and cannot be substituted between sessions.

Skipping issuer authority is a classic failure. A mathematically valid signature proves only that one key signed the data. Trust infrastructure establishes whether that key was authorized to issue the requested credential.

Online, proximity and cross-device are different flows

The framework supports both online and offline or proximity interactions.

• Remote presentation sends a request from an online service to a wallet and returns the result over an internet protocol.
• Proximity presentation lets a nearby reader interact with the wallet, commonly using QR, NFC or Bluetooth-related mechanisms depending on the profile.
• Cross-device presentation begins on one screen and uses a wallet on another device, often with a QR-mediated handoff.

The user experience may look similar, but the transcript and security binding differ. A QR code should carry or resolve a transaction-specific request—not act as an unprotected shortcut around the relying party's authenticated session.

Registration is part of authentication

Article 5b of Regulation (EU) 2024/1183 requires wallet-relying parties to register where they are established. The registered record includes identity, contact information, intended use and requested data.

The wallet must be able to identify the relying party to the user. The relying party's technical certificate or authentication mechanism therefore connects to its legal registration and declared data scope.

This is why an intermediary cannot promise anonymous, instant production access for any customer. It can simplify software and operate infrastructure, but the underlying relying party and purpose still need an authorized place in the ecosystem.

Selective disclosure is a protocol feature, not a full privacy programme

A credential format can disclose only requested claims. That reduces exposure, especially compared with collecting document images.

The relying party still needs to answer:

• Why is each attribute necessary?
• Is identification required, or would a predicate or pseudonym suffice?
• What is retained after verification?
• Which processors receive the result?
• What happens when the wallet or credential is unavailable?
• How are consent, denial and errors recorded?

Cryptographic minimisation makes a better privacy architecture possible. It does not write the data-protection policy on the relying party's behalf.

Where an orchestration layer fits

An application often wants a small outcome—identify this person, establish an age threshold, or bind a person to an action—without implementing every wallet, format and trust route independently.

An orchestration layer can normalize those outcomes while preserving the distinctions underneath. To do that honestly, it needs a canonical route that includes at least:

• jurisdiction;
• credential profile;
• wallet or presentation provider;
• delivery mode;
• supported primitive;
• relying-party registration state;
• issuer trust availability; and
• sandbox or production status.

Collapsing those dimensions into “country supported” creates false coverage. The same country can have multiple wallets and credentials, and one wallet can carry credentials from several jurisdictions.

That route-ledger model is how Alentra approaches wallet aggregation. The public API can stay small, while the verification layer remains explicit about what is actually live.

For the nontechnical overview, start with the complete EUDI Wallet guide. If you operate the receiving service, continue with the EUDI relying-party readiness guide.