Digital Identity Wallets: EUDI and mDL Integration

Q: Do I have to rebuild onboarding to accept EU Digital Identity Wallets?

No. The most common and expensive mistake is treating the EUDI Wallet as a new onboarding system requiring a migration project. A wallet credential is a presentation your service verifies, not an identity your service stores, so it slots in behind the verification step you already run. The wallet does not change what you are trying to establish at signup — that this person is who they claim and old enough, licensed enough, or resident enough to use the service. It changes the evidence format: instead of a photographed document you OCR and a selfie you match, you receive a cryptographically signed, selectively disclosed attestation the user's device presents over a standard protocol. The correct integration is an added branch — "present from wallet" offered beside document capture, with document capture kept as the fallback for users who do not yet have a wallet — verifying the issuer signature and reading the disclosed claims. Most of the work is additive and can ship in a sprint, not a rebuild.

Q: When must EU member states provide the wallet, and does my product have to accept it?

Regulation (EU) 2024/1183, known as eIDAS 2.0, entered into force in May 2024 and requires every EU member state to make at least one EU Digital Identity Wallet available to its citizens and residents within 24 months of the relevant implementing acts, which places the deadline in late 2026. Acceptance obligations follow: the regulation requires relying parties in defined sectors, and very large online platforms, to accept the wallet when users choose to present it, with those obligations phasing in after wallets are available. The practical planning consequence is that users across the EU will have wallets within your next product renewal cycle, and if you operate in a regulated sector — financial services, telecoms, platforms above the size thresholds — accepting wallet presentations moves from optional to mandatory. Even where you are not strictly obligated, accepting the wallet lowers your per-check cost and raises fraud resistance, so it is worth building ahead of the mandate rather than after it.

Q: What is the difference between mDL/mdoc and W3C verifiable credentials or SD-JWT VC?

They are two credential lineages you will support in parallel. The ISO/IEC 18013-5 mobile driving licence uses the mdoc format with selective disclosure and defines data elements such as age_over_NN, so a wallet can prove "over 18" or "holds a Class B licence" without releasing the licence number, name, or address; ISO/IEC 18013-7 extends mdoc to unattended online presentment over the web. The other lineage is the W3C Verifiable Credentials Data Model 2.0, a Recommendation since 15 May 2025, most commonly carried on the wire as SD-JWT VC, which uses salted disclosures to achieve the same field-level selective release. mdoc is the natural format for government-issued identity and entitlement documents; SD-JWT VC is common for sector and reusable-KYC credentials issued by banks and other accredited parties. The EUDI Architecture and Reference Framework profiles both, so a conformant relying party verifies whichever format the wallet presents. The verification model — check the issuer signature against a trust list, read only the disclosed fields — is the same for both.

Q: How is a verifiable presentation verified?

Verification is local and does not require a call to a central identity server at presentation time. Your service sends a request for specific claims (for example age_over_18 and given_name) using OpenID for Verifiable Presentations; the user consents in the wallet and selects a credential; the wallet returns a signed presentation containing only the requested fields; and your backend verifies the issuer's signature against a trust list of accredited issuers, checks revocation or status, and reads the disclosed claims. The trust list is where the security actually lives — a signature you do not check against an accredited-issuer list proves nothing, because anyone can sign a JSON blob. A key privacy property is that the issuer that signed the credential never learns which service requested it, and you never receive fields you did not ask for, so there is no shared identifier letting issuer and relying party correlate the user across services. This unlinkability is a design property of the framework, not something you add on top.

Q: What should I store after a wallet presentation?

Store the disclosed claims and a verification receipt proving a check occurred — never the presented credential itself or a copy of the underlying document. If the gate needed "over 18", you keep the age_over_18 boolean and a signed receipt; if it needed residency, you keep the locality and a receipt. You do not need to retain evidence you can simply re-request from the wallet later, and retaining the full credential recreates exactly the identity honeypot the selective-disclosure format was designed to eliminate. This is the same reversible-token and minimise-at-capture discipline used in PII-redaction pipelines: persist an opaque, actionable claim plus proof of verification, and design the store so those records can be deleted on request. Treating the wallet as "a better ID scanner" and storing the whole presentation is the failure mode — you inherit all the breach liability of document-based KYC while discarding the privacy advantage that made the wallet worth integrating. The audit requirement is proof that verification happened, which a receipt satisfies without holding the identity material.

Q: What is selective disclosure and why does it matter for KYC?

Selective disclosure is the ability of a wallet to prove a specific claim without revealing the rest of the credential — proving age_over_18 without releasing the date of birth, or proving a driving entitlement without releasing the licence number and address. In the mdoc format this is built into ISO/IEC 18013-5 as per-field release; in SD-JWT VC it is achieved with salted, individually disclosable claims. It matters for KYC because it lets you satisfy a regulatory or business requirement with the minimum data, which is both a data-minimisation obligation under privacy law and a direct reduction in your breach exposure. The reusable rule is to request the minimum the gate needs: a service that must confirm adulthood should request age_over_18, not full date of birth; an address check should request the locality, not the whole document. Teams that request the whole credential "to be safe" defeat the entire privacy value and fail data-minimisation review, rebuilding the honeypot the format exists to prevent. Selective disclosure is what makes accepting a wallet a privacy improvement rather than merely a format change.

Q: Is a valid credential the same as a valid holder?

No, and conflating them is a real security gap. A valid signature proves the credential was issued by an accredited issuer and has not been altered or revoked; it does not by itself prove that the person presenting it is the legitimate holder rather than someone holding a stolen, unlocked device. Wallet-to-holder binding — the wallet's own device unlock, biometric, or PIN, and cryptographic binding of the credential to the wallet instance — is what connects the credential to the person, and its strength is a property of the wallet, not of your verification. For low-stakes gates a valid presentation is sufficient; for high-stakes actions such as a large transaction or an account-recovery step, you still layer your own device and session assurance and step-up on top, exactly as you would in an account-takeover defence design. The correct mental model is that the wallet presentation raises baseline assurance and cuts fraud, but it composes with, rather than replaces, your existing risk scoring and step-up for the actions that matter most.

Q: What protocols and standards do I integrate against, and do I build them myself?

You profile existing standards rather than inventing anything. The credential formats are ISO/IEC 18013-5 and 18013-7 (mdoc, for the mobile driving licence and its online presentment) and the W3C Verifiable Credentials Data Model 2.0 carried as SD-JWT VC. The wire protocols are OpenID for Verifiable Presentations (OpenID4VP) for presentation and OpenID for Verifiable Credential Issuance (OpenID4VCI) for issuance. The EU Digital Identity Wallet Architecture and Reference Framework specifies exactly which formats, protocols, and trust mechanisms a conformant integration must use, and the European Commission publishes implementation guidance and a reference wallet alongside it. Use conformant, well-maintained OpenID4VP and OpenID4VCI libraries and the reference implementations; building a bespoke protocol will fail interoperability and conformance testing and lock you out of cross-border acceptance. The integration surface on your side is a claims request, a signature verification against a trust list, revocation and freshness checks, and a decision — a well-bounded piece of work, not a new identity platform.

Satyam Kumar

Zurück zum Blog

cyber-security-patterns

Digital Identity Wallets: Integrating EUDI and mDL Without Rebuilding Onboarding (2026)

By Satyam KumarSeptember 19, 202611 min read

eudi wallet eu digital identity wallet eidas 2.0 verifiable credentials mobile driving licence iso 18013-5 mdoc credential format sd-jwt vc openid4vp digital identity onboarding kyc architecture selective disclosure reusable identity w3c vc data model issuer trust list decentralized identity

Digital Identity Wallets: Integrating EUDI and mDL Without Rebuilding Onboarding (2026)

Frequently Asked Questions

Artikel teilen

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

KI & Cloud Architekt. Ich helfe Teams, Systeme zu bauen, die auf Millionen skalieren.

LinkedIn GitHub

Digital Identity Wallets: Integrating EUDI and mDL Without Rebuilding Onboarding (2026)

Frequently Asked Questions

Artikel teilen

Comments

Leave a comment