EUDI Wallet Architecture: OpenID4VCI, OpenID4VP, SD-JWT VC and mdoc Under eIDAS 2.0

Most explanations of the EUDI wallet describe it as “a digital ID in your phone”. That framing hides the interesting part. The European Digital Identity Wallet is a protocol stack, a trust framework and a hardware-security contract bundled together, and a bank that integrates it is signing up for all three. Get any one layer wrong and you either leak user data, fail certification, or build an onboarding flow that cannot work across borders.

This matters now because Regulation (EU) 2024/1183, the revision commonly called eIDAS 2.0, obliges every Member State to offer a wallet to its citizens, with launches widely expected around the end of 2026. The OpenID wire protocols reached Final status in 2025, the Architecture and Reference Framework (ARF) reached version 3.0.0 in July 2026, and relying-party obligations are following. This post is a systems analysis, not legal or financial advice.

You will leave with a layered mental model of the wallet, a precise understanding of how credentials are issued (OpenID4VCI), presented (OpenID4VP and ISO mdoc), selectively disclosed (SD-JWT VC), and attested (wallet unit attestation), plus a failure-mode list and a concrete plan for banking use cases such as KYC onboarding and PSD2 strong customer authentication.

What this covers: the regulatory frame, the actors and trust model, issuance and presentation protocols, the two credential formats, privacy and unlinkability limits, banking integration patterns, and what goes wrong in production.

Context and Background

Regulation (EU) 2024/1183 was adopted on 11 April 2024 and entered into force on 20 May 2024. It amends the 2014 eIDAS Regulation (910/2014) and introduces the European Digital Identity Wallet. Member States must provide a wallet within a fixed period after the Commission adopts the implementing acts, and the wallet must be free of charge for natural persons. The first sets of implementing regulations were adopted in December 2024, May 2025 and July 2025, and a further round of amendments was published in July 2026, according to the Commission’s digital-building-blocks pages and trade reporting. The “end of 2026” launch date is therefore best read as the expected deadline derived from those acts, rather than a single fixed legal day. Check your own Member State’s national timetable before committing a roadmap.

For banks and payment institutions the headline provision is the acceptance obligation. Article 5f requires that private relying parties that must apply strong user authentication under law or contract, banking and financial services among them, accept the wallet for that purpose. In other words, the wallet is not an optional extra identity method for regulated finance. It is a mandatory acceptance channel, which makes the technical details below commercially relevant rather than academic.

The technical backbone is the Architecture and Reference Framework, an open document maintained on GitHub by the Commission together with Member State experts. Version 3.0.0 was released on 23 July 2026. According to the release notes it aligns the ARF with the amended implementing regulations on person identification data (PID) and electronic attestations of attributes (EAA), wallet integrity and core functions, protocols and interfaces, and registration of wallet-relying parties. It also introduces a “Relying Party Services” concept, new requirements to consume both ETSI Trusted Lists (TS 119 612) and Lists of Trusted Entities (TS 119 602), and a Functional Conformance Assessment Framework with shared test cases. Trade reporting expects only small updates from here, though that is an expectation, not a commitment.

The protocol layer is borrowed from the wider ecosystem. OpenID for Verifiable Credential Issuance 1.0 was published as Final on 16 September 2025, and OpenID for Verifiable Presentations 1.0 as Final on 9 July 2025. The OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0 was approved as a Final Specification following a member vote that ran 9 to 23 December 2025. The selective-disclosure primitive, SD-JWT, was published as RFC 9901 in November 2025, while the credential-format layer SD-JWT VC remains an IETF OAuth working-group Internet-Draft (revision 19 at the time of writing). The mobile-driving-licence lineage contributes ISO/IEC 18013-5 and its mdoc data model.

For related regulated-finance identity architecture, see our analysis of passkeys and FIDO2 for PSD2 payment authentication and of perpetual KYC architecture, both of which sit on either side of the wallet in a real bank stack. For the legal text itself, consult Regulation (EU) 2024/1183 on EUR-Lex.

Reference Architecture: Actors, Wallet Unit and Trust Anchors

In one paragraph: the EUDI wallet is a user-controlled application, backed by a secure cryptographic device, that receives signed credentials from issuers over OpenID4VCI and presents selected attributes to registered relying parties over OpenID4VP or ISO 18013-5. Trust does not come from a central directory of users but from signed trust lists that tell each party which issuers, wallet providers and relying parties are legitimate.

Figure 1: The EUDI wallet ecosystem. Credentials flow in through OpenID4VCI, attributes flow out through OpenID4VP or proximity mdoc, and trust lists sit beside every arrow.

Figure 1 shows the actors. The long description for accessibility: on the left are PID providers and attestation providers (issuers), in the centre the wallet unit consisting of the app, secure hardware and the wallet provider backend, and on the right the relying parties, with a trust-list publisher feeding all three groups.

The wallet unit is more than an app

The ARF defines a wallet unit as the combination of the wallet instance on the user’s device, the secure cryptographic application and device that protect keys (WSCA/WSCD), and the wallet provider’s backend. This matters because security claims live in the combination. A pure software wallet with keys in application storage cannot achieve the assurance level the regulation expects for PID. The WSCD may be a secure element, an eSIM-based element, or a remote HSM-backed service, depending on the Member State’s implementation. The ARF leaves room for several, which is a source of fragmentation we return to in the trade-offs section.

Four roles, three trust relationships

There are four principal roles. The wallet provider supplies and certifies the wallet unit. PID providers issue the core identity credential, a government-backed attestation of name, date of birth and similar attributes. Attestation providers issue everything else, qualified or not: a diploma, a bank account ownership proof, a driving licence. Relying parties consume attributes.

Three trust relationships glue them together. Issuers must trust that the wallet is genuine (answered by wallet unit attestation). Relying parties must trust that the issuer was authorised to issue that attribute (answered by trust lists and certificate chains). Users must trust that relying parties only ask for what they are registered to ask for (answered by relying-party registration and access certificates). Each relationship has a distinct cryptographic mechanism, and mixing them up is the most common design error we see.

Trust lists replace the directory

There is no global identity registry. Instead, Member States publish trusted lists, and the ARF 3.0.0 requirement is that wallets, relying parties and issuers be able to retrieve trust anchors from both the classic ETSI TS 119 612 lists and the newer ETSI TS 119 602 lists of trusted entities. A verifier validating a credential walks the issuer’s certificate chain to an anchor taken from such a list. This is the same pattern as web PKI, but with the anchor set curated by public authorities per credential type and role rather than by browser vendors.

The practical consequence for engineers: trust-list freshness is an operational dependency. A verifier that caches a list for days will accept a certificate that an authority has already withdrawn. Treat list refresh like OCSP stapling, with a defined maximum staleness and alerting.

Issuance: OpenID4VCI and Wallet Unit Attestation

Issuance is where the wallet earns its security properties. A credential is only as good as the proof that its holder key lives in certified hardware, and OpenID4VCI is the protocol that carries that proof.

Figure 2: OpenID4VCI issuance with wallet and key attestation. The issuer checks the wallet before binding any key.

OpenID4VCI in one page

OpenID4VCI 1.0 builds on OAuth 2.0. The issuer exposes a credential issuer metadata document, an authorization server, and a credential endpoint. The specification defines two grant types: the standard authorization_code flow, and the pre-authorized_code grant for cases where the issuer authenticated the user out of band before the wallet connects, such as a bank branch visit or an online identity check.

The flow begins with a credential offer, delivered by QR code or deep link, either by value or by reference. The wallet reads the issuer metadata, obtains an access token, and optionally calls the nonce endpoint for a fresh c_nonce. It then calls the credential endpoint with a proof of possession of the key to which the credential will be bound. If the issuer cannot issue immediately, a deferred credential endpoint lets the wallet poll later, and a notification endpoint reports acceptance or deletion.

Appendix F of the specification defines three proof types: jwt, di_vp and attestation. The attestation proof type is the one that matters for the EUDI context, because it lets the wallet present a signed statement about keys it holds rather than signing a fresh proof per key. Appendix A defines credential-format profiles for W3C Verifiable Credentials, ISO mdoc and IETF SD-JWT VC, so one protocol serves both formats the ARF uses.

Wallet unit attestation: proving the hardware

The ARF’s Wallet Unit Attestation (WUA) is the answer to “is this a genuine, certified wallet with protected keys?”. Earlier ARF versions had two separate artefacts, a wallet instance attestation and wallet trusted evidence; from ARF 1.5 onward they were merged into the WUA concept. Implementation guidance, such as the iGrant.io documentation based on the technical specification (TS3), describes two components issued by the wallet provider:

A wallet instance attestation, short-lived (under 24 hours), used to authenticate the wallet as a client at the token endpoint.
A key attestation, a JWT carrying an attested_keys array that asserts the listed keys were generated in and are bound to the same WSCD at a stated assurance level; for PID the guidance cites iso_18045_high.

A PID provider following that guidance verifies the key attestation’s x5c chain against the wallet-provider trusted list, checks the proof of possession against attested_keys, confirms freshness through the c_nonce, and refuses issuance if the assurance signal is too low. It must also re-check revocation status of both artefacts at least every 24 hours for the credential’s lifetime, and must revoke the PID if the wallet unit is revoked. Treat these numbers as drawn from third-party reading of TS3; confirm against the current specification text before building to them.

A deliberate privacy decision: the ARF states that the WUA is shown only to PID and attestation providers, never to relying parties, since verifiers have no business need to learn the wallet’s hardware properties. That keeps the device fingerprint out of presentations.

Batch issuance and the once-only rule

Unlinkability needs many credential copies. If a wallet holds a single signed credential with a single holder key, every presentation carries the same signature and the same public key, and colluding verifiers can recognise the user. The ARF’s mitigation is batch issuance: the wallet obtains a batch of credential copies with distinct keys and signatures but identical attribute values and validity, and uses each copy once. When unused copies fall below a threshold the wallet requests a new batch.

The cost is real. A batch of 30 copies means 30 attested keys, 30 signatures at issuance, and 30 entries of storage. It also means revocation by the issuer must work across copies without creating a correlating handle, which is why status lists with random indexes and large populations are required rather than per-credential revocation calls.

The Two Credential Formats: SD-JWT VC and ISO mdoc

The ARF deliberately supports two formats rather than choosing one. This is an engineering compromise with consequences for everyone who verifies credentials.

Figure 3: Anatomy of SD-JWT VC and mdoc. Both hide claims behind salted digests, but they package signatures, keys and encoding differently.

How SD-JWT selective disclosure works

RFC 9901 defines the mechanism. The issuer takes each selectively disclosable claim and wraps it as a Disclosure: a base64url-encoded JSON array containing a random salt, the claim name, and the value. The issuer hashes each Disclosure and places the digests in an _sd array in the signed JWT payload, shuffled so the claim order does not leak. The hash algorithm is named in _sd_alg, with sha-256 as the default. Array elements are hidden by replacing them with an object holding a single "..." key whose value is the digest. Issuers may add decoy digests that match no Disclosure, which blurs how many hidden claims exist.

The holder sends the signed JWT plus only the Disclosures it chooses to reveal. The verifier hashes each received Disclosure, confirms the digest appears in the signed payload, and recovers the claim. A claim the holder withheld stays hidden because the salt makes the digest infeasible to guess. For holder binding, the wallet appends a Key Binding JWT signed with the key referenced in the credential’s cnf claim; it includes aud, nonce, iat and an sd_hash that binds it to the exact SD-JWT and chosen Disclosures. This stops a verifier from replaying a presentation elsewhere.

A worked example of the digest arithmetic: a PID with 12 attributes where the issuer adds 4 decoys carries 16 digests of 43 base64url characters each in _sd, roughly 700 bytes before JSON overhead. A presentation revealing only age_over_18 ships one Disclosure of perhaps 60 to 80 bytes. The size win versus the full credential is real, but the signed payload always carries every digest. (Sizes here are illustrative arithmetic, not a benchmark.)

What SD-JWT VC adds

RFC 9901 is just the selective-disclosure format. SD-JWT VC layers credential semantics on top. According to draft 19, the media type is application/dc+sd-jwt and the header typ must be dc+sd-jwt. The mandatory vct claim is a case-sensitive credential type identifier; the draft defines no vct values itself, leaving that to ecosystems. The optional cnf claim carries the holder’s proof-of-possession key and is required for key binding. Registered claims such as iss, nbf, exp, cnf, vct and status cannot be selectively disclosed.

Issuer keys are resolved either through JWT VC Issuer Metadata, fetched from /.well-known/jwt-vc-issuer when iss is an HTTPS URI, or through an x5c certificate chain in the header. If the verifier cannot validate the signing key by a permitted mechanism, it must reject the credential. For EUDI, the x5c route dominates because trust anchors come from trust lists, not from DNS and TLS. Type Metadata, a JSON document describing display and claim definitions, may be retrieved from a URL in vct and protected with the optional vct#integrity hash. Because SD-JWT VC is still an Internet-Draft, pin the draft number your wallet and verifier implement and expect migration work when it becomes an RFC.

ISO mdoc and the mobile security object

The mdoc format comes from ISO/IEC 18013-5, the mobile driving licence standard. Its data elements are organised into namespaces and signed through a Mobile Security Object (MSO), a CBOR structure containing salted digests of each element, the device public key, and validity information, signed by the issuer. Selective disclosure follows the same principle as SD-JWT: the holder releases only the chosen elements and the verifier checks their digests against the MSO. Holder binding works differently, via a device signature over a session transcript, which makes mdoc native to proximity flows over NFC or BLE.

The encoding differences have practical bite. CBOR with COSE signatures is compact and fits constrained hardware and NFC payloads; JSON with JOSE is easier for web teams and general-purpose libraries. The ARF accepts both, so a bank verifier should plan to support both, or accept that some wallet-held credentials cannot be consumed.

Which format for which channel

A simple rule from the protocol design: use mdoc where proximity and offline matter (in-branch, point-of-sale age checks), and SD-JWT VC where remote web and app flows dominate (online onboarding). Both can be carried by OpenID4VP remotely, and OpenID4VCI issues both. The decision is less about cryptographic strength and more about the library ecosystem your engineering team already runs.

Presentation: OpenID4VP, the DC API and Relying-Party Authentication

Presentation is where the relying party gets what it needs, and where most privacy and phishing risks concentrate.

Figure 4: OpenID4VP remote presentation. The verifier sends a signed request with a DCQL query; the wallet returns an encrypted response after consent.

The request: DCQL and signed request objects

OpenID4VP 1.0 was published as Final on 9 July 2025. A verifier describes what it wants with the Digital Credentials Query Language (DCQL), a JSON query. The top level has a required credentials array and an optional credential_sets. Each credential query carries an id, a format, meta (for example the vct values or mdoc doctype accepted), optional trusted_authorities, require_cryptographic_holder_binding (default true) and claims, addressed by claims path pointers and optionally filtered by expected values. Optional claim_sets express alternatives, such as “either full birth date or an age-over attestation”.

Requests are carried as signed JWT-secured authorization requests per RFC 9101, with typ set to oauth-authz-req+jwt; wallets must reject requests lacking it. The request can be passed by value or by reference via request_uri, and with the post method the wallet can send its capabilities and a nonce. An optional transaction_data array lets the verifier bind the presentation to a specific action, such as a payment amount, and wallets must reject transaction-data types they do not recognise. That mechanism is the hook for signing-style flows in banking.

Who is asking: client identifier prefixes

Wallet users need cryptographic evidence of the verifier’s identity. OpenID4VP expresses this through client identifier prefixes of the form <prefix>:<identifier>. Defined prefixes include x509_san_dns (identifier matches a DNS name in the signing certificate), x509_hash (SHA-256 hash of the leaf certificate), verifier_attestation, openid_federation, decentralized_identifier and redirect_uri (which cannot be signed and so offers weak assurance). An identifier without a recognised prefix is treated as pre-registered.

In the EUDI setting, relying parties obtain registration and access certificates, and the wallet checks the request signature against a certificate chaining to a trust anchor. The ARF 3.0.0 text on registration aligns with Commission Implementing Regulation 2025/848. The registration record can state which attributes a relying party is entitled to request; a wallet can warn or refuse when a request exceeds it. Over-asking is therefore detectable in principle, though enforcement depends on wallet behaviour and supervisory practice.

The response: direct_post, encryption and the DC API

For cross-device flows, the wallet returns the response via direct_post, an HTTP POST to the verifier, with direct_post.jwt as the encrypted variant. The verifier advertises supported content-encryption algorithms, with A128GCM as the default. Encrypting the response keeps attribute values away from intermediaries such as logging proxies. The VP token returned is a container for one or more presentations, possibly in different formats.

OpenID4VP 1.0 also defines dc_api and dc_api.jwt response modes for the browser Digital Credentials API, where the browser mediates between a web page and the wallet. Here the origin is supplied by the browser rather than asserted by the verifier, which hardens against phishing. I could not verify from the sources consulted how fully each EU wallet implementation supports the DC API as of November 2026, so treat that as an open item in your own interoperability testing. The HAIP 1.0 profile exists precisely to narrow the optionality: it constrains OpenID4VCI and OpenID4VP choices so independent wallets and verifiers interoperate without bilateral negotiation (consult the HAIP text for its exact required parameters).

Proximity: ISO 18013-5 and what 18013-7 adds

In person, the wallet presents mdoc credentials over NFC engagement and BLE or NFC data transfer under ISO/IEC 18013-5, with session encryption derived from an ephemeral key exchange and reader authentication via the reader’s certificate. ISO/IEC 18013-7 extends the model to online presentation. Reader authentication is the proximity analogue of the signed request object: it lets the wallet display who is asking before releasing data.

Privacy, Unlinkability and the Limits of Zero-Knowledge

Privacy is a stated design goal of eIDAS 2.0, and the regulation text refers to unlinkability and protection against tracking. The honest engineering view is that selective disclosure delivers minimisation, not unlinkability, and unlinkability needs additional machinery.

What selective disclosure does and does not give you

Selective disclosure stops a verifier learning attributes the user did not release. It does not stop two verifiers recognising the same user, because the issuer’s signature and the holder’s public key are constants across presentations of the same credential copy. Colluding verifiers can compare signatures. Even a single verifier plus the issuer can correlate: the issuer knows the signature and digests it produced, so if the verifier shares presentations with the issuer, the user is identified.

Threat	SD-JWT / mdoc alone	With batch issuance	With zero-knowledge proofs
Verifier learns undisclosed attributes	Prevented	Prevented	Prevented
Two verifiers link the same user	Possible via signature or key	Prevented while copies remain	Prevented
Verifier colludes with issuer	Possible	Possible if the issuer records digests per copy	Mitigated, depends on scheme
Single-use copies exhausted	Not applicable	Wallet must reuse or re-issue	Not applicable

Batch issuance as a pragmatic mitigation

The ARF’s chosen near-term mitigation is the batch approach from earlier: use each copy once. It works with the formats already standardised and ships on commodity secure elements. Its weakness is operational. Issuers must provide issuance capacity for batches, wallets need offline reserves, and a user whose copies run out while offline faces either reuse (linkable) or failure. Short validity windows and status lists with herd privacy limit the revocation side channel.

Zero-knowledge proofs: the longer road

Zero-knowledge proofs would let a wallet prove “this signed credential says I am over 18” without revealing the signature at all, removing the constant-signature problem. The ARF and associated academic and regulator discussions treat ZK as the direction of travel, but I could not verify from the sources consulted that a ZK scheme is mandated or standardised in ARF 3.0.0, so this post treats it as roadmap, not requirement. Engineers should note the cost drivers: proof generation on a phone, circuit compatibility with the credential’s signature algorithm (ECDSA over P-256 is the dominant constraint for hardware-backed keys), and the lack of certified secure-element support for ZK-friendly signatures such as BBS. Design verifiers so the credential format is negotiated through DCQL meta, which keeps a later ZK format a configuration change rather than a rewrite.

Data protection in practice

Privacy outcomes depend as much on relying-party behaviour as on cryptography. A bank that asks for the full PID when it needs only an age-over claim, then stores the whole response, defeats the design. GDPR data minimisation and purpose limitation apply in parallel, and the registration regime makes the stated purpose auditable. Log the request’s DCQL and the attribute names received, not the values, wherever your retention policy allows.

Banking Use Cases: KYC Onboarding and Strong Customer Authentication

This section is systems analysis, not compliance advice. Your legal team owns the interpretation of AML, PSD2 and any successor rules.

Remote KYC onboarding

The classic remote onboarding flow asks the applicant to photograph a passport, take a selfie and wait for liveness checks and manual review. The wallet replaces the capture step with a cryptographic one. The bank sends an OpenID4VP request for the PID attributes it needs (family name, given names, birth date, nationality, document or personal identifier as permitted), verifies the issuer signature against the trust list, validates key binding, and receives attributes that were issued by a government-backed provider rather than OCR’d from an image.

The engineering gains are measurable in principle, though I will not quote conversion figures I cannot source. Document forgery and image-injection attacks no longer apply to the identity-proofing step because there is no image. Data quality improves because fields arrive structured. The review queue shrinks because the bank no longer adjudicates photo quality. What remains is binding the wallet session to the account being opened, handling name-matching between PID and sanctions screening data, and deciding which attributes the bank’s AML policy actually requires.

Two points deserve emphasis. First, the PID’s identifier attributes follow Member State rules, so a bank in one country receiving a PID from another must map identifiers rather than assume a format. Second, a presentation is a point-in-time proof. Ongoing due diligence still needs periodic refresh, which is where perpetual KYC patterns take over: re-request only the attributes that can change, and re-run screening on the stored subset.

Strong customer authentication and payment binding

Under PSD2, strong customer authentication requires two independent factors from knowledge, possession and inheritance, and for remote electronic payments a dynamic link between the authentication and the amount and payee. The wallet can serve as the possession and inheritance factor: the key is non-extractable inside the WSCD and use is gated by a local user-verification step such as biometrics or PIN.

The dynamic link is where transaction_data becomes important. A bank can place the payment amount and payee in a transaction-data object bound to the credential query; the wallet must display it and the key binding signature then covers it. Compare this with the FIDO2 passkey approach to payment SCA: passkeys are mature, widely deployed and well integrated into mobile operating systems, whereas the wallet route carries identity attributes alongside authentication and is subject to the acceptance obligation. The two are complementary in practice. Use passkeys for routine session and payment authentication and the wallet for identity events: onboarding, recovery, high-risk limit increases and cross-border account opening.

I have not verified how PSD3 and the proposed Payment Services Regulation will treat wallet-based authentication in final text, since those texts were still moving in the sources I consulted. Flag that as a legal-watch item.

Account recovery and re-binding

Recovery is the unglamorous high-value use. A customer who lost a phone can prove identity afresh with the wallet, and the bank can compare the PID’s persistent identifier with the one stored at onboarding to confirm continuity. Pair that with a cooling-off period before enabling new payees. The wallet gives strong identity continuity; it does not remove the need for risk-based friction.

A worked integration sketch

A minimal verifier for an onboarding flow needs five components: a request builder that signs OpenID4VP requests with the relying party’s access certificate, a response endpoint that accepts direct_post.jwt and decrypts it, a format-aware validator for SD-JWT VC and mdoc, a trust-list client with bounded staleness, and a policy engine mapping received attributes to KYC decisions.

The validation order matters, because each step guards the next:

Decrypt the response and check it matches the state or nonce you issued, rejecting replays.
Verify the key binding signature, including aud equal to your client identifier and the nonce you generated.
Verify the issuer signature and walk the certificate chain to a trust-list anchor, checking the issuer is authorised for that credential type.
Check validity period and revocation status through the credential’s status list reference.
Only then parse claims and hand them to the policy engine.

A compact sketch of the DCQL query for an age-and-name request in SD-JWT VC form follows. The vct value is a placeholder: the PID type identifiers are defined by the ecosystem, so use the value from the current PID rulebook.

{
  "credentials": [
    {
      "id": "pid",
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["<PID-vct-from-rulebook>"] },
      "claims": [
        { "path": ["family_name"] },
        { "path": ["given_name"] },
        { "path": ["birthdate"] }
      ]
    }
  ]
}

Capacity and cost thinking

Two cost lines surprise teams. The first is trust-list and revocation traffic: status lists are cached, but a busy verifier validates thousands of presentations an hour and must refresh lists on a schedule. The second is certificate lifecycle: access certificates for relying parties expire, and a lapsed certificate halts onboarding in the same way an expired TLS certificate halts a website. Monitor expiry with the same rigour. Issuers face the heavier load, because batch issuance multiplies signing operations; an issuer serving a million wallets with batches of 30 signs tens of millions of credentials per refresh cycle (arithmetic, not a measured figure), which argues for HSM capacity planning and rate-limited reissuance.

Trade-offs, Gotchas, and What Goes Wrong

Spec instability beneath a Final label. OpenID4VCI and OpenID4VP are Final, but SD-JWT VC is still an Internet-Draft, and the ARF itself moves in numbered releases. Version-pin everything, test against the Commission’s reference implementation and the conformance suite, and budget for migration.

Format duplication. Supporting both SD-JWT VC and mdoc doubles your validation surface. Each format has its own signature container, its own trust-chain semantics and its own bugs. Fuzz both parsers, and prefer maintained libraries over hand-rolled CBOR or JOSE handling.

Over-collection. The easiest mistake is requesting the whole PID because it is simpler than writing a minimal DCQL query. It is also the mistake regulators and registration records will catch. Ask for the narrowest attribute set and store the narrowest result.

Trust-list lag. A verifier with a stale list accepts withdrawn issuers or rejects newly added ones. Define maximum staleness and a degraded-mode policy: fail closed for onboarding, possibly fail open with extra checks for low-risk logins.

Hardware fragmentation. The ARF permits several WSCD architectures. A wallet whose keys sit in a remote HSM has different threat properties from one in a local secure element, and key attestation values can differ. Do not assume uniform assurance; read the attestation.

Linkability through side channels. Even with batch issuance, a wallet that reuses a copy, a verifier that logs the issuer signature, or a status-list index that is not randomised re-introduces correlation. Review logs as a privacy surface.

User-experience cliffs. Offline reserves running out, device migration, and restoring credentials after a phone loss are unsolved ergonomics problems. Design a fallback onboarding path, since the acceptance obligation sits on the relying party but customers without a compatible wallet cannot be turned away from banking altogether (confirm the legal position with counsel).

Phishing and consent fatigue. Signed requests and registration certificates help only if the wallet shows the verifier identity prominently and users read it. The DC API’s browser-supplied origin helps, but the human step remains.

Unverified items. I could not confirm the precise state of national wallet launches in November 2026, the ZK roadmap in the ARF, or DC API support across wallets from the sources consulted. Check before you publish commitments to stakeholders.

Practical Recommendations

Treat the wallet as a new external identity provider with unusual properties: it is user-hosted, cryptographically attested, and regulated. Integrate it behind your existing identity abstraction rather than scattering wallet logic through onboarding code. Start with a narrow, high-value flow, usually remote onboarding for existing-country residents, prove it in a sandbox with the Commission’s reference wallet and a conformance run, then widen to cross-border and recovery.

Build the verifier as a service with its own trust-list client, certificate management and format validators, so every channel (web, app, branch) shares it. Keep the policy layer separate, because AML and SCA rules change faster than cryptography. Write DCQL queries per use case in version control, review them like database schemas, and make “least attribute” a code-review rule.

On the people side, involve your data-protection officer early. The registration regime makes your purpose declarations public, and mismatches between declared and requested attributes are visible.

Checklist before go-live:

Pin versions of OpenID4VCI, OpenID4VP, HAIP, SD-JWT VC draft and the ARF release you target.
Register as a wallet-relying party and obtain access certificates; monitor expiry.
Implement both SD-JWT VC and mdoc validation, or document the exclusion.
Enforce key binding, nonce, aud and replay checks on every presentation.
Bound trust-list and status-list staleness; alert on refresh failure.
Request minimal attributes; log names, not values.
Provide a non-wallet fallback and a recovery path.
Run the conformance test cases and an interoperability session with at least two independent wallets.

Frequently Asked Questions

What is the EUDI wallet?

The EUDI wallet is the European Digital Identity Wallet created by Regulation (EU) 2024/1183, which amends eIDAS. It is an app, backed by secure cryptographic hardware, that stores government-issued identity data and other attestations and presents selected attributes to registered services. Each Member State must provide one to its citizens and residents at no charge, and it is the mechanism through which cross-border identity and credential exchange will work across the EU.

When will EUDI wallets be available?

Member States must provide wallets within a fixed period after the implementing acts, and the widely cited expectation is that launches occur around the end of 2026. The first implementing regulations were adopted from December 2024, with further sets in 2025 and amendments published in July 2026. Exact national dates differ, and I could not verify each country’s status, so check your Member State authority and the Commission’s pages for current timelines before planning.

What is the difference between OpenID4VCI and OpenID4VP?

OpenID4VCI is the issuance protocol: it lets a wallet obtain a credential from an issuer using an OAuth-based flow with credential offers, a token step and a credential endpoint. OpenID4VP is the presentation protocol: it lets a relying party request, and a wallet return, selected attributes through a DCQL query and a signed request. Both reached Final status in 2025 and are used together in the EUDI architecture.

What is the difference between SD-JWT VC and mdoc?

Both support selective disclosure through salted digests, but they differ in encoding and ecosystem. SD-JWT VC uses JSON and JOSE, builds on RFC 9901, and suits web and remote flows. The mdoc format comes from ISO/IEC 18013-5, uses CBOR and COSE with a Mobile Security Object, and suits proximity and offline use. The EUDI ARF supports both, so verifiers generally need to handle both formats.

Does the EUDI wallet protect privacy against tracking?

Partly. Selective disclosure prevents verifiers learning attributes the user withheld, and the ARF uses batch issuance with single-use credential copies to reduce linkability across verifiers. It does not by itself stop collusion between issuer and verifier, and zero-knowledge proofs, which would address more cases, are a roadmap direction I could not verify as mandated. Privacy also depends on relying parties requesting minimal data.

Must banks accept the EUDI wallet?

Article 5f of Regulation (EU) 2024/1183 requires private relying parties that are obliged to use strong user authentication, including in banking and financial services, to accept the wallet for that purpose, subject to the regulation’s timing and conditions. How this interacts with PSD2 and its successors in practice is a legal question, so consult counsel and your supervisor rather than relying on this summary.