Regulation, protocols, credential formats and trust infrastructure, all overlapping. These are the terms you meet while integrating, without the specification prose.
eIDAS 2.0 is Regulation (EU) 2024/1183, adopted on 11 April 2024. It amends the original eIDAS Regulation and requires every member state to offer an EU Digital Identity Wallet to the natural and legal persons in the Union. The public sector has to accept one. Named private relying parties and very large online platforms have to accept one where the user asks to use it.
The EU Digital Identity Wallet is an app provided under each member state’s scheme that holds a person’s government-issued identity data and other verified attributes, then presents selected parts of them to services under the holder’s control.
The Architecture and Reference Framework is the technical reference for the EU Digital Identity Wallet, produced by the European Digital Identity Cooperation Group together with the Commission as part of the Common Union Toolbox. It sets out the roles, protocols, credential formats and trust model that wallets, issuers and relying parties implement to interoperate. It is informative. What binds is the regulation and its implementing acts.
The European Business Wallet is a proposed wallet for companies and other legal entities, published by the Commission on 19 November 2025 as COM(2025) 838. It is a separate draft regulation rather than part of eIDAS 2.0, and it is not law yet.
An attestation rulebook specifies one credential type in full: attribute set, encodings, mandatory and optional fields, credential format and trust requirements. Rulebooks are written by Attestation Scheme Providers and listed in the Commission catalogue of attestation schemes. They are what makes credentials interoperable in practice.
OpenID4VP is the protocol a relying party uses to ask a wallet for credentials and get a signed presentation back. The ARF requires it for remote presentation, profiled by HAIP. It runs over two transmission mechanisms, a custom URI scheme or the W3C Digital Credentials API. Proximity flows, where both devices are physically present, use ISO/IEC 18013-5 instead.
OpenID4VCI is the protocol an issuer uses to deliver a credential into a wallet. It covers the credential offer, holder authorisation, proof of key possession, and issuing the signed credential itself.
DCQL is the query language a verifier uses inside an OpenID4VP request to say which credentials and which individual claims it needs. OpenID4VP 1.0 dropped Presentation Exchange in favour of it, and the ARF picks that up by pointing at OpenID4VP and HAIP rather than defining a query language of its own.
Cross-device flow is when the user sits at a desktop and scans a QR code with the phone holding their wallet. Same-device flow is when they are already on the phone and a deep link opens the wallet. Both are OpenID4VP. Only the delivery differs.
Person Identification Data is the core government-issued identity credential in an EU Digital Identity Wallet. It carries what a member state holds about a person: names, date of birth, nationality, address and derived age proofs, all signed by the issuing state.
A mobile driving licence is a driving licence issued as a signed digital credential under ISO/IEC 18013-5. It carries driving privileges, categories, expiry and issuing authority as structured data that a verifier checks against the issuer signature.
An electronic attestation of attributes is a signed statement about a person or organisation from someone other than the state identity issuer: an employer, a university, a bank, a professional body. eIDAS 2.0 also defines qualified (QEAA) and public-body (PuB-EAA) variants with stronger legal effect.
SD-JWT VC packages claims as a signed JWT where individual claims can be withheld at presentation without breaking the issuer signature. It is one of three attestation formats the ARF recognises, alongside ISO/IEC 18013-5 mdoc and W3C VCDM v2.0, and it is identified by the media type dc+sd-jwt.
mdoc is the CBOR-based credential format from ISO/IEC 18013-5, identified as mso_mdoc. It uses a Mobile Security Object holding digests of each data element, which is what lets elements be disclosed selectively.
Device binding ties a credential to a private key held inside the wallet’s secure cryptographic device or keystore. Presenting it requires proving control of that key, so a copied credential is useless to anybody else. ISO/IEC 18013-5 calls it mdoc authentication, SD-JWT VC calls it key binding.
Trust anchors sit in two kinds of list. Member States publish national Trusted Lists of qualified trust service providers, which inside the wallet ecosystem cover QEAA providers only. Everyone else who needs a trust anchor goes on a List of Trusted Entities signed and published by the Commission. A verifier checks an issuer against whichever list applies before relying on its signature.
Relying party registration requires a verifier to register in the member state where it is established, declaring who it is and which attributes it intends to request. Wallets check that registration and must warn the holder when a verifier asks for more than it registered for. Whether the wallet then blocks the request is left to each wallet provider’s risk policy.
A Wallet Unit Attestation is a credential from the wallet provider about one installed wallet. PID providers and attestation providers use it at issuance to confirm they are issuing into a genuine certified wallet rather than an impostor app. It is never shown to a verifier.
A status list is a compact public bitstring encoding the validity of many credentials at once. Each credential carries an index into it, so a verifier can check revocation without asking the issuer about that specific holder.
A qualified trust service provider is an organisation supervised by a member state and granted qualified status for one or more specific trust services. Those include issuing qualified certificates, timestamps and attestations of attributes, and managing remote signature and seal creation devices. Its status and the services it covers appear on the national trusted list.
eIDAS defines three assurance levels for electronic identification: low, substantial and high. They describe how much confidence a relying party can place in a claimed identity. The EU Digital Identity Wallet operates at high.
Selective disclosure means revealing specific claims from a credential while withholding the rest, without invalidating the issuer signature over what you do reveal. It is how a verifier can learn that someone is over 18 without learning their birth date.
A wallet pseudonym is a stable identifier a holder presents to one relying party. By default the wallet never hands the same pseudonym to a second relying party, and colluding relying parties cannot tell two pseudonyms belong to one person. It lets a service recognise a returning user without learning who they are.
Salted hash disclosure is the mechanism behind SD-JWT selective disclosure. The issuer signs hashes of salted claim values rather than the values, and the holder reveals a claim by sending the salt and value so the verifier can recompute the hash.
A qualified electronic signature is made with a qualified signature creation device using a qualified certificate tied to a verified identity. Under eIDAS it has the same legal effect as a handwritten signature and every member state has to recognise it.
An electronic seal is the organisational counterpart to a signature. A legal entity creates it rather than a person, and it proves the origin and integrity of a document that entity issued.
