The European Digital Identity Wallet (EUDI Wallet) is a mobile application, issued or recognised by every EU Member State, that lets a citizen or a business store and present verifiable identity data. Under the revised eIDAS Regulation, each Member State must offer at least one wallet to its residents, and a wide range of private-sector services must accept it. For online platforms, this is the first time a legally recognised, cross-border identity layer exists that does not depend on scanning a passport photo.
What the wallet actually holds
A wallet is a container for cryptographically signed attestations. Three families matter in practice:
- Person Identification Data (PID) — the core identity set issued by the Member State: name, date of birth, national identifier.
- Qualified Electronic Attestations of Attributes (QEAA) — issued by Qualified Trust Service Providers and carrying the highest legal weight.
- Non-qualified Electronic Attestations of Attributes (EAA) — issued by any organisation that can vouch for an attribute: employment status, membership, licence, customer tier, professional qualification.
Each attestation is signed by its issuer and bound to the wallet's device key. When the user presents it, your service verifies the signature chain rather than trusting a scanned document — which removes the entire category of forged-document fraud.
Why this is a B2B story, not just a citizen story
The obligation to accept the wallet falls on service providers. Banks, telecoms, platforms subject to strong customer authentication, and very large online platforms will have to accept wallet-based identification where they already require identity. Everyone else gains an optional but much cheaper onboarding path: no document capture, no liveness video, no manual review queue.
The catch is that accepting a wallet credential is not a simple API call to a single provider. You become a Relying Party in a regulated trust framework, which brings registration, access certificates, and conformance obligations.
What changes in your onboarding flow
- Your service requests a specific set of attributes — and only those attributes.
- The user's wallet shows exactly what is being requested and by whom, then consents.
- The wallet returns a signed presentation, typically in mdoc/mDL or SD-JWT VC format.
- Your service verifies signatures, revocation status, and the issuer's place on the EU Trust List.
- You keep the attributes you are legally allowed to keep — usually far fewer than a document scan gave you.
The three costs nobody budgets for
- Registration: each Member State runs its own Relying Party registration process, with its own forms, timelines and national supervisory body.
- Access certificates: presentation requests must be signed with certificates that expire and must be rotated across every wallet ecosystem you touch.
- Conformance drift: the Architecture and Reference Framework (ARF) and the implementing acts keep evolving. An integration that conforms today needs maintenance to still conform in two years.
The technical integration is a few weeks of work. The regulatory surface around it is a permanent function — which is exactly the part worth outsourcing.
The intermediary route
An intermediary Relying Party is registered in the ecosystem on its own account and performs presentation requests on behalf of other organisations. You integrate once, against one API, and the intermediary carries registration, certificate lifecycle, multi-wallet compatibility and continuous conformance. This is the model Arkadiz operates: a single integration that covers multiple wallets and multiple Member States, so your product team ships an onboarding flow instead of a compliance programme.
Where to start
Map the identity checks you run today, and for each one write down the minimum attribute set that would satisfy it. In most cases the honest answer is much smaller than what you collect now — often a single boolean such as "is over 18" or "is a licensed professional". That list is the specification for your first wallet integration, and it is also your strongest GDPR data-minimisation argument.