How to Accept EUDI Wallet Credentials: A Practical Integration Guide

Once you have decided to accept EUDI Wallet credentials, the question shifts from "why" to "how exactly does this work on Tuesday afternoon in our staging environment". This guide walks through the protocol, the format choices, the verification logic, and the operational checklist you need before flipping the switch in production.

The protocol: OpenID4VP in one page

The EUDI Wallet ecosystem standardises on OpenID for Verifiable Presentations (OpenID4VP) as the exchange protocol between a Relying Party (you) and the wallet. The flow is deliberately close to familiar OAuth/OIDC patterns, which is good news for engineering teams that already run SSO integrations.

1. Your backend builds an authorization request describing exactly which attributes you need, expressed as a presentation definition (DCQL or the older presentation exchange format).
2. The request is signed with your access certificate and delivered to the wallet, typically via a QR code (cross-device) or a deep link (same-device).
3. The wallet parses the request, checks your Relying Party registration and certificate against the trust infrastructure, and shows the user a consent screen listing exactly what is requested and by whom.
4. On consent, the wallet returns a VP token containing one or more signed credential presentations to your redirect/response endpoint.
5. Your backend verifies the token, extracts the disclosed attributes, and continues your business flow.

Nothing here requires you to store a copy of an ID document. You request attributes, not documents — a subtle but legally important distinction that shapes your entire data retention policy.

mdoc vs SD-JWT VC: which format to request

Two credential formats coexist in the ecosystem, and your presentation request should be able to handle both because different wallets and Member States favour different ones during the rollout period.

• ISO/IEC 18013-5 mdoc — the format inherited from mobile driving licence work. Encoded as CBOR, verified with COSE signatures, strong hardware-backed device binding. Common for PID and mDL-style attestations.
• SD-JWT VC — a JSON-based format with selective disclosure: the issuer signs a set of claims, and the holder discloses only a chosen subset while the signature still verifies. Easier to parse and debug, increasingly preferred for non-qualified EAAs.
• Both support selective disclosure and cryptographic binding to the wallet's device key, so pick based on issuer support and your parsing stack, not on trust properties — neither format is inherently "more secure" than the other.

Designing the presentation request

The single biggest integration mistake is over-asking. Every attribute in your request must map to a genuine legal or business need, because the wallet's consent screen literally lists them for the user to see — a bloated request looks suspicious and increases abandonment.

• Start from the decision you need to make (age above threshold, licence validity, employment status) and work backwards to the minimal attribute set.
• Prefer predicate disclosures ("over 18: true") over raw values (date of birth) whenever the credential format and issuer support it.
• Scope requests per use case rather than reusing one broad request template across your product.

Verification: what you must actually check

Receiving a VP token is the easy part. A correct verifier performs several independent checks, and skipping any one of them turns your integration into a compliance liability.

1. Signature validity on the credential and, where present, on the presentation itself (key binding proof).
2. Issuer trust: is the issuer's certificate anchored in the applicable EU Trust List or national trusted list?
3. Revocation status of the credential, checked against the issuer's status mechanism (status list, OCSP-style, or equivalent).
4. Freshness: nonce and audience binding to prevent replay of a captured presentation.
5. Schema and semantic checks on the disclosed claims before they touch your business logic.

A verifier that checks the signature but not the trust list, or the trust list but not revocation, is not half-secure — it is a fraud vector waiting for someone to find it.

UX: consent flows people actually complete

Wallet-based verification is faster than document upload, but only if the surrounding flow does not add friction back in. Test the cross-device QR flow on a real second phone, not just a simulator, and design an explicit fallback for users without a compatible wallet yet — this population will shrink but is not zero during the rollout years.

Testing and go-live checklist

• Test against each Member State conformance/test wallet you plan to support, not just one reference implementation.
• Verify certificate rotation does not break in-flight requests during a deployment window.
• Load-test the presentation-request signing path — it is a new cryptographic operation in your critical request path.
• Confirm your data retention logic actually discards attributes you were not legally entitled to keep.
• Run a joint test with your registered Relying Party identity in at least one Member State's acceptance environment before public launch.

Where an intermediary changes the equation

Everything above is standard, well-documented protocol work — and also a permanent maintenance surface once multiple Member States, wallet versions and certificate cycles are in play. Arkadiz operates as the registered intermediary Relying Party: you send one verification request to one API, and it handles OpenID4VP transport, format negotiation, trust list checks and revocation across every supported wallet, so your team ships the product flow rather than re-testing a protocol stack every time an implementing act changes.