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, 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 protocols, the regulation and the controls a relying party needs, and is written for identity architects, CIAM and fraud teams, and the executives who own the compliance deadline.
Key takeaways
- Verification replaces inspection. Wallet-based identity swaps visual checks of document images for cryptographic verification of attributes signed by an issuer you have chosen to trust.
- Selective disclosure is the privacy win. A relying party can ask for "over 18" instead of a full date of birth, and the EU regulation forbids registered relying parties from asking for more than they registered.
- The relying party still does the hard checks. Issuer signature against a trusted list, revocation status, device binding and replay protection are your job; OpenID4VP says a verifier must not rely on the wallet to enforce its constraints.
- EU deadlines are fixed in law. Regulation (EU) 2024/1183 requires wallets within 24 months of its implementing acts (the Commission says by the end of 2026), and many regulated private relying parties must accept them within 36 months.
- Plan for coexistence. Wallet use is voluntary under the EU regulation, so documents, national eIDs, bank identity schemes and wallets will run side by side for years.
The building blocks
Wallet ecosystems use the issuer, holder and verifier model. NIST SP 800-63C-4 describes the same pattern as a "subscriber-controlled wallet": the credential service provider issues signed attribute bundles that include the wallet's verification key, and the wallet then acts as an identity provider towards relying parties. Identity wallets hold identity attributes; they are a different thing from cryptocurrency wallets (see the Crypto Wallet Security Guide for those).
| Term | What it is |
|---|---|
| Issuer (PID or attestation provider) | An organisation that signs attributes about a person, such as a government, university, bank or employer. The EU framework calls core identity data person identification data (PID) |
| Holder (user) | 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. NIST also recognises hosted "cloud wallets" |
| Verifiable credential (attestation) | A tamper-evident set of claims signed by an issuer. W3C VCDM 2.0, SD-JWT VC and ISO mdoc are the main formats |
| Mobile driving licence (mDL) | A driving licence in the mdoc format defined by ISO/IEC 18013-5, for in-person and online presentation |
| Decentralised identifier (DID) | A W3C identifier whose keys are resolved without a central registry; used in some ecosystems but not all |
| Trusted list | A published list of recognised issuers, wallet providers and registrars that verifiers use to decide whom to trust. The EU architecture uses Trusted Lists and Lists of Trusted Entities (LoTE) |
| Device binding and user binding | Device binding proves the credential sits in the key store it was issued to; user binding (often called holder binding) means the presenter is the person it was issued to |
Credential formats
The EU Architecture and Reference Framework (ARF) compares the three standard formats as follows. Wallets in the EU ecosystem must support the first two; W3C VCDM support is optional and meant for non-qualified attestations only.
| Format | Encoding | Selective disclosure | Typical use |
|---|---|---|---|
| ISO/IEC 18013-5 mdoc (generalised in ISO/IEC 23220-2) | CBOR (binary) | Salted hashes embedded in the signed object | Proximity presentation, such as an mDL shown to a reader |
| SD-JWT VC | JSON Web Token | Salted hashes, as defined in RFC 9901 (SD-JWT) | Remote presentation, such as online identification |
| W3C Verifiable Credentials Data Model 2.0 | JSON-LD | Detached or embedded proofs, depending on the securing mechanism | General purpose; needs profiling for interoperability |
How a wallet presentation works
- Request: the relying party asks for specific attributes, for example age over 18 and nationality. In OpenID4VP the request carries a Digital Credentials Query Language (DCQL) query, and in the EU it carries a registration certificate stating the intended use.
- Relying party authentication: the wallet checks who is asking and, in the EU, that the request does not exceed the attributes the relying party registered.
- Consent: the wallet shows the person who is asking and why, and asks for approval, unlocked by a device biometric or PIN.
- Presentation: the wallet releases only the approved attributes, signed by the issuer, with a proof of possession of the bound key over the verifier's nonce and identifier.
- Verification: the relying party checks the issuer signature against a trust anchor from a trusted list, checks revocation, verifies device binding and confirms the response is tied to its own request.
| Protocol | Publisher and status | What it does |
|---|---|---|
| OpenID for Verifiable Presentations (OpenID4VP) 1.0 | OpenID Foundation, final specification (July 2025) | Request and presentation of credentials of any format on top of OAuth 2.0, same-device or cross-device, including over the browser Digital Credentials API |
| OpenID for Verifiable Credential Issuance (OpenID4VCI) 1.0 | OpenID Foundation, final specification (September 2025) | OAuth-protected API through which a wallet obtains credentials, with an authorisation code or pre-authorised code flow |
| OpenID4VC High Assurance Interoperability Profile (HAIP) | OpenID Foundation | Profiles OpenID4VC with SD-JWT VC and ISO mdoc so issuers, wallets and verifiers interoperate |
| ISO/IEC 18013-5 and 18013-7 | ISO/IEC | 18013-5 covers mDL proximity presentation; 18013-7 covers remote presentation of mdoc credentials |
OpenID4VP is explicit that it "requires profiling to achieve interoperability", which is why the EU ecosystem pins down formats and options through HAIP and its rulebooks. See the OAuth 2.0 and OpenID Connect Guide for the underlying OAuth security practices.
The regulatory picture
This is an orientation, not legal advice.
| Jurisdiction | Instrument | What it means for relying parties |
|---|---|---|
| European Union | Regulation (EU) 2024/1183 (European Digital Identity Framework, often called eIDAS 2.0) | Wallets from every member state; registration before relying on wallets; acceptance duties for public bodies, regulated private services and very large online platforms |
| United Kingdom | UK digital verification services trust framework 1.0, under Part 2 of the Data (Use and Access) Act 2025 | Certified digital verification services you can rely on; certified providers may use the UK CertifID trust mark |
| United States | NIST SP 800-63-4 (federal guidance) | Treats subscriber-controlled wallets as a federation model, and accepts cryptographically verifiable digital evidence in identity proofing |
European Union
- Availability: each member state must provide at least one European Digital Identity Wallet within 24 months of the entry into force of the implementing acts. The European Commission says wallets will be available to every citizen, resident and business by the end of 2026.
- Assurance and cost: wallets are provided under an electronic identification scheme at assurance level high, and their issuance, use and revocation are free of charge for natural persons.
- Public sector: where a member state requires electronic identification for an online public service, it must also accept the wallet.
- Private relying parties: those required by law or contract to use strong user authentication for online identification, including in transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education and telecommunications, must accept the wallet on the user's voluntary request no later than 36 months from the entry into force of the implementing acts. Micro and small enterprises are excluded.
- Very large online platforms: where they require user authentication, they must accept the wallet on the user's voluntary request, for the minimum data necessary.
- Voluntary use: access to services must not be restricted or made disadvantageous for people who do not use a wallet, and other identification means must remain available.
United Kingdom and United States
The UK published the final 1.0 version of its digital verification services trust framework in June 2026, and the government expected it to come into force on 1 September 2026 once conformity assessment bodies are accredited. In the US, NIST SP 800-63A-4 adds a digital evidence pathway in which presenting a cryptographically verifiable attribute bundle with a local activation factor counts as verification of SUPERIOR evidence. The Identity Security Regulatory Map covers related identity obligations, and the Global Privacy Regulatory Map covers the data protection side.
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 and the Deepfake and AI Impersonation Guide.
- Less data: selective disclosure means you can stop collecting and storing full document copies you do not need. OpenID4VP says verifiers should request only the minimal set of claims needed for the stated purpose.
- Registration duties: in the EU a relying party must register in the member state where it is established, declare its intended use and the data it will request, identify itself to the user and keep its registration up to date. Intermediaries acting for relying parties are treated as relying parties and must not store data about the content of the transaction.
- Pseudonyms: under the EU regulation relying parties must not refuse pseudonyms where identification is not required by law, so login journeys should support a wallet-generated pseudonym as well as full identification.
- New integration work: presentation protocols, trust anchor management, revocation checks and fallback routes, often delivered through an identity verification or CIAM platform. See the Customer IAM (CIAM) Guide.
Risks to manage
- Replay and injection: OpenID4VP requires the proof of possession to be bound to the verifier's client identifier and a fresh nonce, and the verifier must reject any presentation that does not carry the right nonce. A presentation without holder binding, the specification warns, may have been obtained from a third party.
- Holder binding failures: a credential shared or relayed by someone other than its holder. The ARF makes device binding mandatory for PIDs and mdoc credentials but only recommended for SD-JWT VC, so request a binding proof where risk demands it.
- Over-asking: requesting more attributes than needed undermines the privacy benefit and, in the EU, breaches the registration rules. Wallets check requests against registration certificates.
- Phishing of presentations and issuance: a fake relying party requesting credentials, or a stolen credential offer. OpenID4VCI notes that anyone holding a valid pre-authorised code could receive a credential without further measures, and requires implementers to add mitigations.
- Revocation gaps: the ARF requires revocation information in any PID or attestation valid for more than 24 hours, but checking it is recommended rather than mandatory, and offline verifiers may have no current status list.
- Tracking and linkability: issuer signatures and bound keys can link presentations across verifiers. The ARF risk register lists linkability and collusion between relying parties as threats; batch issuance and one-time use of each credential instance reduce them.
- 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 and to software acting for them.
- Legal persons: the EU framework provides wallets for legal persons as well as natural persons, and treats providers of attested attributes such as licences and "powers and mandates to represent or act on behalf of natural or legal persons" as trust service providers. For business onboarding, see the KYB Guide.
- AI agents: a W3C Community Group formed in April 2026 is working on an agent credential format based on W3C Verifiable Credentials that binds an AI agent to its controlling organisation, alongside revocation and trust negotiation. See the Agent Identity Standards Tracker, the Agentic Commerce Identity Guide and the Zero Trust for AI Agents Guide.
- Your own verifier is a non-human identity: relying party instances hold access and registration certificates and signing keys. Manage them like any other machine credential. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Framework mapping
Wallet acceptance is a new pattern, so these verified mappings show where existing controls apply.
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|---|
| Accepting externally issued credentials and proofed identities | PR.AA-02, PR.AA-03 | IA-8, IA-8(2), IA-12(6) | 5.16 Identity management | 6.1 Access granting process |
| Verifying presentations (signature, nonce, audience) | PR.AA-04 | IA-5(2), SC-23 | 8.5 Secure authentication | 16.10 Secure design principles |
| Trust anchor management and vetted verifier components | PR.AA-01 | SC-17, SC-12 | 8.24 Use of cryptography | 16.11 Vetted security modules |
| Data minimisation and unlinkability | PR.DS-01 | IA-8(6), PT-3, SI-12(1) | 5.34 Privacy and protection of PII | 3.1 Data management process |
| Document image retention after wallet adoption | PR.DS-01 | SI-12 | 5.34 Privacy and protection of PII | 3.4 Enforce data retention |
| Wallet, verifier SDK and identity verification suppliers | GV.SC-05, GV.SC-07 | SA-9, SR-6 | 5.19, 5.20 Supplier relationships | 15.1, 15.4 Service providers |
| Logging and monitoring of presentations | DE.CM-09, DE.AE-02 | AU-2, AU-6, SI-4 | 8.15 Logging, 8.16 Monitoring activities | 8.2, 8.11 Audit logs |
| Legal obligations (eIDAS acceptance and registration) | GV.OC-03 | PT-2 | 5.34 Privacy and protection of PII | 3.1 Data management process |
Common failure patterns
- Trusting the wallet to filter: assuming that because the request asked for "over 18", the response can only contain that. OpenID4VP states the verifier "MUST NOT rely on the Wallet to enforce these constraints" and must run its own checks.
- Skipping the nonce: reusing a static nonce or not checking it, which leaves the door open to replayed or injected presentations.
- Accepting unbound credentials for high-risk actions: a credential without device binding can be copied. Use the
require_cryptographic_holder_bindingoption or reject unbound credentials for account opening and payments. - Stale trust anchors: loading trusted lists once at go-live. The ARF expects relying parties to download the latest Trusted Lists and LoTEs regularly and remove invalidated entities.
- Silent fail-open on revocation: treating "status list unavailable" as "valid". The ARF asks for a documented risk decision instead.
- Keeping the old evidence anyway: moving to wallet presentation but still storing a full document scan "just in case", which keeps all the breach exposure the wallet was meant to remove.
- Fallback journeys as the weak link: attackers go to whichever route is weakest. Visual checks of faces and documents are not authentication, as the Arup Deepfake Fraud 2024 showed for video calls. See the Identity Fraud Prevention Guide.
- Using a claim as an account key without the issuer: OpenID4VP requires a claim used for authentication to be stable, never reassigned and always combined with the issuer identifier, otherwise an attacker can obtain the same claim from another issuer.
Detection and monitoring
Wallet presentations generate their own signals. Log each verification outcome with the issuer, credential type, binding result, revocation result and the reason for any rejection, without storing the disclosed attributes themselves. Alert on spikes in signature or nonce failures, presentations bound to the same key across many accounts, repeated revoked credentials, and sudden shifts of traffic to fallback journeys. OpenID4VP says verifiers should not fingerprint users from wallet metadata, so monitor transactions, not people. See the Synthetic Identity Fraud Guide for patterns that combine genuine and fabricated attributes.
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Share of identity checks completed by wallet presentation | Adoption and readiness for acceptance duties | Up |
| Attributes requested per journey compared with the registered minimum | Data minimisation in practice | Down to the minimum |
| Presentations verified with revocation and binding checks | Completeness of verifier controls | Up, towards 100% |
| Time from trusted list change to deployment in all verifier instances | Trust anchor hygiene | Down |
| Stored document images held for wallet-verified customers | Breach exposure removed by wallets | Down |
| Fraud rate on fallback journeys compared with wallet journeys | Whether attackers are shifting to weaker routes | Gap narrowing |
| Wallet verification failures by cause | Integration quality and attack activity | Down, with causes explained |
See the Identity Security Metrics Guide for how to report these alongside other identity measures.
How to prepare
- Scope: identify which journeys will be required or able to accept wallets, by jurisdiction and sector, and whether you are a micro or small enterprise outside the EU acceptance duty.
- Minimise: decide which attributes each journey genuinely needs, and design for minimum disclosure and pseudonymous login where identification is not legally required. A DPIA is the natural place to record this.
- Trust: choose the issuers, wallets and trust frameworks you will accept, and map their assurance to your levels.
- Register: in the EU, register each intended use with your national registrar before relying on wallets, and keep the registration current.
- Integrate: implement presentation protocols, trusted list handling, revocation and binding checks, often through an identity verification or CIAM provider. See the CIAM Buyer's Guide.
- Keep alternatives: maintain document-based and other routes for people without wallets, with equivalent controls.
- Retire data: if you no longer need document copies, stop collecting and storing them. See the Data Retention and Secure Deletion Guide.
Implementation roadmap
| Phase | Actions | Outcome |
|---|---|---|
| First 30 days | Confirm legal obligations and dates per jurisdiction; inventory identity journeys and the attributes each collects; name an owner for wallet acceptance | Scope and accountability agreed |
| Days 31 to 90 | Choose formats and protocols (mdoc, SD-JWT VC, OpenID4VP); select a verifier component or provider; define attribute minimums and pseudonym handling; prepare registration information | Design and supplier decisions made |
| Days 91 to 180 | Build or configure verification with trusted list management, revocation and binding checks; register as a relying party; pilot one journey; add logging and alerts | One journey live with full verifier controls |
| After 180 days | Extend to remaining journeys; retire document image storage for wallet-verified users; review fallback fraud; track standards changes such as ISO/IEC 23220-4 | Wallets are a normal, measured identity route |
Practitioner checklist
- Confirm whether eIDAS wallet acceptance or national schemes apply to your services, and by when.
- Register each intended use as a relying party where frameworks require it, and keep it current.
- Request only the attributes each journey needs, using selective disclosure and pseudonyms where allowed.
- Verify issuer signatures against current trusted lists on every presentation.
- Bind every presentation to your client identifier and a fresh nonce, and reject mismatches.
- Require device binding for high-risk actions and verify the binding proof.
- Check revocation status, and document the decision when status is unavailable.
- Run your own checks on returned credentials instead of trusting the wallet to filter.
- Map wallet assurance to your identity assurance levels.
- Keep secure fallback routes and plan for lost or compromised wallets.
- Stop storing document images once wallet-based evidence is available.
Standards and references
- EUR-Lex: Regulation (EU) 2024/1183 establishing the European Digital Identity Framework
- European Commission: European Digital Identity
- European Commission: EUDI Wallet Architecture and Reference Framework, data model and data exchange protocols
- European Commission: EUDI Wallet Architecture and Reference Framework, trust model
- OpenID Foundation: OpenID for Verifiable Presentations 1.0
- OpenID Foundation: OpenID for Verifiable Credential Issuance 1.0
- IETF: RFC 9901 Selective Disclosure for JSON Web Tokens
- W3C: Verifiable Credentials Data Model v2.0
- W3C: Decentralized Identifiers (DIDs) v1.0
- NIST: SP 800-63C-4 Federation and Assertions
- NIST: SP 800-63A-4 Identity Proofing and Enrollment
- GOV.UK: Final release of the 1.0 trust framework
Related NHI Mgmt Group resources: Identity Proofing and KYC Guide · Age Assurance Guide · Privacy-Enhancing Technologies Guide · Agent Identity Standards Tracker. This guide summarises the European Digital Identity Framework and related rules and is not legal advice.