Digital Identity Wallets Guide: eIDAS 2.0, mDL and VCs

Digital identity is moving from "upload a photo of your passport" to "present a signed credential from your phone". Governments are issuing national eIDs and mobile driving licences, the EU requires every member state to offer a European Digital Identity Wallet by the end of 2026, and verifiable credentials let any trusted issuer sign attributes that a relying party can check cryptographically. For relying parties this promises stronger assurance, less data collection and less friction. It also moves trust to new places: issuers, wallets, trust lists and the binding between a credential and the person presenting it. This guide explains the building blocks, the regulation, and how relying parties should prepare.

Key takeaways

Wallet-based identity replaces visual inspection of documents with cryptographic verification of signed attributes.
Selective disclosure lets people share only what is needed, such as "over 18" rather than a full date of birth.
The relying party still has to decide which issuers and wallets to trust, check holder binding and handle revocation.
In the EU, eIDAS 2.0 makes wallets available by 24 December 2026 and requires many regulated private relying parties to accept them within a set period.
Plan for coexistence: documents, national eIDs, bank identity schemes and wallets will run side by side for years.

The building blocks

Term	What it is
Issuer	An organisation that signs attributes about a person, such as a government, university, bank or employer
Holder	The person who stores credentials in a wallet and decides what to share
Verifier (relying party)	The service that requests and checks credentials
Wallet	An app, often backed by secure device hardware, that holds credentials and keys
Verifiable credential	A tamper-evident set of claims signed by an issuer. The W3C Verifiable Credentials Data Model 2.0 is one format; SD-JWT and ISO mdoc are others
Mobile driving licence (mDL)	A driving licence in mdoc format, defined by ISO/IEC 18013-5, for in-person and online presentation
Decentralised identifier (DID)	A W3C-standard identifier whose keys are resolved without a central registry; used in some ecosystems but not all
Trust list	A published list of recognised issuers and wallet providers that verifiers use to decide whom to trust
Holder binding	Proof that the person presenting a credential is the one it was issued to, usually through a key held in the wallet

How a wallet presentation works

The relying party requests specific attributes, for example age over 18 and nationality, and states why.
The wallet shows the person who is asking and what for, and asks for consent, typically unlocked by a device biometric or PIN.
The wallet presents only the requested attributes, signed by the issuer, with a proof that it holds the bound key.
The relying party checks the issuer's signature against a trust list, checks the credential has not been revoked, and verifies holder binding.

Protocols such as OpenID for Verifiable Presentations (OpenID4VP) and OpenID for Verifiable Credential Issuance (OpenID4VCI) standardise how wallets talk to verifiers and issuers, and ISO/IEC 18013-7 covers online presentation of mDLs.

The regulatory picture

This is an orientation, not legal advice.

European Union: Regulation (EU) 2024/1183 (eIDAS 2.0) requires each member state to provide at least one European Digital Identity Wallet by 24 December 2026. Private relying parties that must use strong user authentication in sectors such as banking, financial services, telecommunications, transport, energy, health and digital infrastructure, and very large online platforms, must accept the wallet on request within 36 months of the relevant implementing acts. Micro and small enterprises are excluded from the acceptance duty.
United Kingdom: the UK digital identity and attributes trust framework 1.0 was published in June 2026 under the Data (Use and Access) Act 2025, certifying digital verification services that organisations can rely on.
United States: many states issue mobile driving licences, and federal agencies such as the TSA accept some of them at checkpoints. Adoption by private relying parties is growing.
Elsewhere: national digital ID systems such as India's Aadhaar and the many schemes built on open-source platforms show different models of central and federated identity.

The Identity Security Regulatory Map covers related identity obligations.

What changes for relying parties

Stronger assurance: a signed credential from a trusted issuer is far harder to forge than a document image, which helps against the forgery and deepfake attacks described in the Identity Proofing and KYC Guide.
Less data: selective disclosure means you can stop collecting and storing full document copies you do not need.
New trust decisions: which issuers, wallets and trust frameworks you accept, and at what assurance level.
New failure modes: lost or stolen phones, compromised wallets, revoked credentials and wallet recovery that is weaker than the original issuance.
New integration work: presentation protocols, trust list handling, revocation checks and fallback routes.

Risks to manage

Holder binding failures: a credential shared or relayed by someone other than its holder. Check device binding and use liveness or a local biometric where risk demands.
Over-asking: relying parties requesting more attributes than needed, undermining the privacy benefit. Some frameworks register what each relying party may request.
Phishing of wallet presentations: a fake relying party requesting credentials. Registered and authenticated relying parties reduce this risk.
Revocation gaps: accepting a credential that has been revoked because the check was skipped.
Tracking and linkability: presentations that let different relying parties correlate a person's activity.
Wallet recovery: if re-issuing a wallet after a lost phone is weak, it becomes a new takeover route. See the Account Recovery and Help Desk Security Guide.

Organisational identity and AI agents

The same model applies to organisations: the EU framework includes wallets for legal persons and signed attestations of attributes such as company registration and powers of representation. See the KYB Guide.
Verifiable credentials are also being explored to describe AI agents, what they are and who they act for. See the Agent Identity Standards Tracker and the Agentic Commerce Identity Guide.

How to prepare

Identify which of your journeys will be required or able to accept wallets, by jurisdiction and sector.
Decide which attributes each journey genuinely needs, and design for minimum disclosure.
Choose issuers, wallets and trust frameworks you will accept, and map their assurance to your levels.
Plan the integration: presentation protocols, trust lists, revocation and holder binding checks, often through an identity verification or CIAM provider. See the CIAM Buyer's Guide.
Keep document-based and other routes for people without wallets, with equivalent controls.
Update data retention: if you no longer need document copies, stop storing them.

Practitioner checklist

Confirm whether eIDAS 2.0 wallet acceptance or national schemes apply to your services and by when.
Request only the attributes each journey needs, using selective disclosure.
Verify issuer signatures against trust lists, check revocation and verify holder binding on every presentation.
Register and authenticate your service as a relying party where frameworks require it.
Map wallet assurance to your identity assurance levels.
Keep secure fallback routes and plan for lost or compromised wallets.
Reduce storage of document images once wallet-based evidence is available.

Standards and references

Related NHI Mgmt Group resources: Identity Proofing and KYC Guide · Age Assurance Guide · Customer IAM (CIAM) Guide · Agent Identity Standards Tracker

Digital Identity, eID and Identity Wallets Guide