Who takes part, what the wallet holds, how data moves and why anyone can trust it. The terms you meet while learning or integrating, without the specification prose.
An issuer signs a credential into the user’s wallet. The user decides what to share with a relying party, which checks it against the trust layer. Click any term to read it.
Issuer
Signs credentials: a member state, university, bank or employer
Issuance
EUDI Wallet
Belongs to the user, who decides what to share
Presentation
Relying party
The service that requests and checks the data
Trust layer: who is allowed to sign, and is it still valid?
Rules: the law and technical framework behind it all
Where Authbound fits
The wallet belongs to the user. Authbound works on the relying party side: it creates the wallet request, verifies the presentation including issuer trust, revocation and device binding, and returns a structured result to your application. For issuers, it can create OpenID4VCI credential offers from your records.
Verification docs →Issuance docs →Integration guide →Timeline by country →Use cases →
The organisations that issue, provide, check and rely on wallet data.
A relying party is a public or private service that asks an EU Digital Identity Wallet for data and relies on what it receives, such as a bank opening an account or a shop checking age. Under eIDAS 2.0 it has to register in the member state where it is established before relying on wallets.
A wallet provider is the organisation that provides an EU Digital Identity Wallet solution to users. It can be the member state itself, a body the member state mandates, or an independent provider the member state recognises. Its wallet has to be certified before it is offered.
A PID provider is the body a member state makes responsible for issuing and revoking Person Identification Data and for binding a user’s PID to their wallet unit. It verifies the user’s identity at assurance level high before issuing.
Attestation provider is the ARF’s collective name for anyone who issues electronic attestations of attributes into a wallet: qualified trust service providers issuing QEAAs, public sector bodies issuing PuB-EAAs, and other organisations issuing non-qualified EAAs.
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.
Used in 1 use case
An intermediary is an organisation that interacts with wallets on behalf of one or more relying parties, requesting and receiving user attributes for them. eIDAS 2.0 treats an intermediary as a relying party and forbids it from storing data about the content of the transaction.
The wallet itself, the credentials inside it and how they are encoded.
The EU Digital Identity Wallet is an app, backed by secure hardware that protects its keys, provided under each member state’s scheme. It holds a person’s government-issued identity data and other verified attributes, and presents selected parts of them to services under the user’s sole control.
Person Identification Data is the core government-backed identity credential in an EU Digital Identity Wallet. It always carries the person’s names and date of birth, and may add nationality, address and derived age proofs. It is issued and signed by the PID provider the member state designates.
Used in 10 use cases
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.
Used in 1 use case
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.
Used in 5 use cases
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.
Used in 2 use cases
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.
Used in 1 use case
The EU age verification app is a Commission blueprint for proving you are over 18 online without revealing who you are. Member states customise it as a standalone app or build it into their EU Digital Identity Wallet, and a Commission recommendation of April 2026 asks them to make it available by the end of 2026.
Used in 2 use cases
How an issuer puts data into a wallet and how a service asks for it.
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.
Used in 7 use cases
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.
Used in 1 use case
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.
Used in 2 use cases
How a verifier knows a credential is genuine, current and in the right hands.
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.
Used in 4 use cases
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.
Used in 6 use cases
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.
Used in 5 use cases
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.
Used in 3 use cases
How the wallet shares only what is needed and stops services tracking users.
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.
Used in 4 use cases
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.
Used in 2 use cases
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.
Used in 1 use case
Legally binding signing and sealing with the wallet.
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.
Used in 3 use cases
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.
Used in 1 use case
The regulation, implementing acts and technical framework behind the wallet.
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.
Used in 1 use case
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.
Used in 1 use case
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.
Last reviewed 7 October 2026 against the ARF and the eIDAS 2.0 implementing acts. Each term notes whether it is a legal term, ARF term or technical standard. See how these terms show up in real use cases.
