A wallet presentation is not “a QR code containing a JWT.” It is a protocol between an issuer, a person’s wallet and a relying party, with trust, consent, data minimization, status and interoperability rules that the backend must verify deliberately.
The European Digital Identity (EUDI) Wallet framework is moving from specifications and pilots toward national implementations and ecosystem testing. EU Member States are required to provide wallets by the end of 2026. The Commission’s 2026 testing work brings wallet teams, issuers, relying parties and labs together to test real interoperability, including OpenID for Verifiable Credential Issuance (OpenID4VCI), OpenID for Verifiable Presentations (OpenID4VP) and proximity flows based on ISO/IEC 18013-5.
For application teams, the important shift is architectural: identity data is held and presented through a user-controlled wallet, while the relying party must authenticate itself, request only registered and justified attributes, validate the presentation and make a purpose-bound decision. A successful signature check alone does not establish that every other trust condition is satisfied.
Issuer, wallet provider and relying party are distinct security roles. An issuer’s claim is not made trustworthy merely because it is stored in a wallet. The verifier needs a trust framework for issuers and credential types, and must validate that the presented data is cryptographically bound to the expected holder or wallet unit according to the selected format and profile.
In an issuance flow, the wallet obtains an offer or authorization, authenticates as required, receives a credential from an issuer and stores it under wallet protections. In a presentation flow, the relying party creates a request with a nonce, audience and requested claims; the user reviews the purpose and disclosure; the wallet returns a proof or presentation; and the verifier validates it against trusted keys, issuer metadata, status and transaction context.
OpenID4VCI and OpenID4VP are protocol families with profiles and implementation details. Follow the EUDI Architecture and Reference Framework, applicable implementing acts and the exact interoperability profile used by the deployment. Do not treat a pilot profile, draft specification and legally mandated production configuration as interchangeable.
Good consent UX cannot repair an unnecessarily broad request. If a service only needs to know whether a person is over a threshold age, request an age predicate or the narrowest supported attribute rather than date of birth and full identity. If a relying party asks for claims beyond those in its registered access certificate, the wallet ecosystem’s rules provide for clear user warnings and explicit approval; silence or a preselected checkbox is not a substitute.
Backend design should define the purpose, requested claim set, retention, legal basis and downstream use before constructing a presentation request. Store the result of the business decision where possible instead of copying the full credential into an account profile. Minimize logs: request identifiers, verifier registration, decision outcome and credential type may be enough; avoid logging the raw presentation, proof or personal attributes by default.
| Use case | Over-collection pattern | Better request / backend result |
|---|---|---|
| Age-gated service | Full date of birth plus address and document number. | Request a supported age threshold proof; retain only eligibility outcome and audit reference. |
| Professional qualification | Entire credential and unrelated personal attributes copied to CRM. | Validate issuer, qualification and validity; store the minimum evidence needed for the decision. |
| Account onboarding | Reuse identity data for analytics or marketing without a separate purpose review. | Keep verification fields separate from optional profile and marketing preferences. |
| Payment or travel flow | Persist every disclosed claim indefinitely for support convenience. | Set field-level retention and deletion behavior; keep a transaction receipt without excess attributes. |
Trust lists and registration data are operational dependencies: cache with a bounded lifetime, monitor refresh failures and define behavior when the trust source is unavailable. A fail-open policy may admit untrusted claims; a fail-closed policy may block users. The right response depends on transaction risk and must be deliberate, documented and observable.
Selective disclosure is not identical to unlinkability. Reusing stable identifiers, correlating timestamps, collecting device metadata or calling issuer/status services on every presentation may allow transactions to be linked. Review what the wallet, verifier, issuer, trust-list operator, status service and analytics stack can observe together. Prefer pairwise identifiers where supported and appropriate, short-lived transaction handles, minimized telemetry and clear retention limits.
Credential status is another tradeoff: a verifier needs to know whether a credential is valid without turning status checks into a tracking beacon. Use the mechanisms required by the applicable profile, understand their privacy properties and avoid extra callbacks that reveal more than necessary. Threat-model screenshots, support exports, crash reports and fraud tooling as part of the same personal-data path.
I would put a verifier gateway in front of business services. It would authenticate relying-party configuration, construct allowlisted requests from versioned transaction policies, handle protocol callbacks, validate proofs and issuer trust, check status and replay, then return a compact signed decision receipt. The receipt could include transaction ID, policy version, credential type, issuer reference, validation outcome and timestamp, but not the full credential unless a specific lawful need requires it.
Contract tests would cover malformed proofs, expired and revoked credentials, wrong audience, replayed nonce, untrusted issuer, over-broad claim request, stale trust data and status-service outage. Store synthetic credentials in test fixtures. Make protocol and trust-library upgrades explicit dependencies in change management, and test interoperation against current reference implementations and ecosystem acceptance environments.
| Failure | Signal | Control |
|---|---|---|
| Signature is valid but issuer is not trusted | Verifier accepts a cryptographically valid credential from an unapproved source. | Validate trust chain, issuer authorization, credential type and policy. |
| Presentation replay | Previously captured response is accepted for a new transaction. | Bind nonce and audience, enforce expiry and maintain replay protection. |
| Relying party asks for extra attributes | Request exceeds registered claims or stated purpose. | Compare with registration and require clear warning and explicit user action as applicable. |
| Trust/status data is stale | Cached issuer keys or revocation state exceed allowed freshness. | Bound cache age, alert on refresh failures and use risk-based outage behavior. |
| Credential payload leaks into logs | Personal claims appear in traces, analytics or support tickets. | Redact by default, use synthetic test data and scan telemetry for forbidden fields. |
EUDI wallet integration is a distributed trust protocol with human-readable consent and backend obligations. Separate issuer, wallet and relying-party roles; request the minimum claims; validate proof, issuer, status and transaction context; and keep credential contents out of logs and downstream profiles by default. Interoperability testing is not a final polish step: it is how implementations discover where their trust assumptions fail.
Editorial note: Ecosystem specifications and rollout work evolve. This article reflects official materials checked September 28, 2026 and is not legal, identity-proofing or certification advice. Follow the current EUDI framework, implementing acts and national wallet guidance for each integration.