The EU Digital Identity Wallet is often described in blog posts and conference keynotes at a level that sounds simple and inspiring, and almost never at the level where you can actually decide what to build. The gap sits between the marketing summary and the architecture reference framework, and it is exactly where most organizations get stuck.
In this session, Richard Esplin, Head of Product at Dock Labs, and Agne Caunt, Product Owner at Dock Labs, worked through that middle layer. They separated EUDI into its business, legal, and technical parts, explained the three credential types that most conversations wrongly collapse into one, and mapped out the difference between state wallets and private wallets, including what each can and cannot hold.
If you are trying to figure out whether you should be a relying party, an issuer, or a wallet provider, and what that actually costs you in registration and technical lift, the insights below are the practical guide the topic usually lacks.
Regulation and Structure
- EUDI is best understood as three layers working together: business, legal, and technical (the "BLT" model borrowed from Drummond Reed). Agne argued that most confusion about EUDI disappears once you identify which of the three layers a given claim or document is actually about.
- The 2014 eIDAS framework worked for government-to-citizen transactions but saw low adoption, limited cross-border use, and almost no private sector participation. The 2024 revision (eIDAS 2) changes this by requiring every member state to make a wallet available that is free for citizens, voluntary to use, and interoperable across all 27 countries. It also adds mandatory acceptance in regulated sectors (banks, telecoms, transport, health, and large platforms) and constrains verifiers to their declared purposes.
- Richard's read is that Europe deliberately concentrated its innovation on the legal and business governance layers, not the technical layer. They kept established technology such as X.509 certificates because it already works, treating a project of this scale and timeline as the wrong place to also invent new cryptography or key management.
Credentials
- EUDI has three credential types with materially different rules: PID (Personal Identity Document, the digital national ID, issuable only by a government or a government-mandated entity), QEAA (Qualified Electronic Attestation of Attributes, issued by an audited qTSP), and EAA (Electronic Attestation of Attributes, non-qualified and issuable by essentially any organization, which the slides label the "unregulated" issuer path).
- Agne's practical framing: when a customer asks "can we issue credentials in EUDI," the honest first response is "which credentials are you talking about," because the three types collapse together in high-level conversations and the distinction changes everything downstream.
- Issuing a credential and issuing an EUDI-compliant credential are not always the same decision. PIDs and QEAAs must use SD-JWT VC or mdoc under the ARF; EAAs can use those formats for interoperability but are free to use other platforms and formats when the use case calls for privacy-preserving approaches, cross-ecosystem exchange, or monetization that the ARF does not yet address.
Wallets
- There are two wallet categories: state wallets (required by regulation, certified, able to carry the PID) and private wallets (built to the same standards, cannot carry the PID, but can carry QEAAs and EAAs). Users can hold as many wallets as they want, and Agne expects many people to hold both a state wallet and multiple private wallets.
- A "wallet" does not have to be a standalone app. Private wallets can be embedded inside applications a user already has, so from the user's point of view there may be no distinct wallet at all, just their identity flowing through a service.
- Whether QEAAs can sit in private wallets is still contested across jurisdictions. Based on the DICE conference, Agne observed that different countries see their state wallets very differently: France leans toward PID-only, while Denmark's approach was described (as a joke made by a French representative) as a "vending machine" that wants to include everything useful to the citizen.
- Wallet certification is happening state by state, and each state decides where its PID can live. France has said it will not use Apple, Google, or Samsung wallets, while other states are more open. Richard noted all three big tech providers are lobbying to be accepted, but acceptance is a per-state decision.
- Consumer comfort with big tech wallets is higher than EU policy instincts assume. Agne cited research across five countries (Italy, France, Spain, UK, Germany) showing that in most of them, people were nearly as comfortable storing identity documents in big tech wallets as in government wallets, with Italy an exception at under 30 percent comfort.
Missing Technical Capabilities
- EUDI deliberately omits several technologies identity specialists might expect. It does not use W3C JSON-LD or full RDF tooling (choosing the simpler SD-JWT VC route), does not use W3C DIDs or decentralized key management (all key management runs through X.509 certificate infrastructure that already exists), and does not use zero-knowledge proofs.
- Richard explained the ZKP omission concretely: the enabling cryptography is not approved by SOG-IS. Note the nuance the appendix slide adds: Curve P-256 is included in SOG-IS, so it is the ZKP-specific cryptography that is unapproved, not the base curve. To handle unlinkability and age verification without ZKPs, EUDI relies on batch issuance, giving a holder many single-use copies of a credential and pre-defined age brackets (over 16, over 18, over 65, with exact brackets still being decided). ENISA is looking at updating the cryptography standards.
- Decentralization has a designated home elsewhere: the slides note JTC-19 as the EU blockchain services push for decentralized identity, separate from the mainline EUDI approach.
Participation Paths
- There are three ways to participate, defined by distinct articles of eIDAS 2: relying party (Article 5b), issuer (Articles 45b through 45h, with QEAA specifically under Article 45d), and wallet provider (Article 5a for functionality, 5c for certification). They are not mutually exclusive, but most organizations will land in one or two.
- Realistic expectation: nearly everyone will be a relying party, few will become qTSP-level official issuers, and almost no private company will pursue the full EUDI wallet provider certification path because it is expensive and heavy.
- For relying parties, the intermediary role (permitted under Article 5b) lets smaller organizations delegate registration, certificate handling, and integration to a third party rather than registering directly in each member state's register. Both speakers see this as the most realistic path for smaller companies. The registrar issues a wallet relying party access certificate (the mandatory piece); the slides clarify that registration certificates, by contrast, are optional and member-state dependent.
- Richard raised a genuine adoption concern: requiring verifiers to register their use cases with the state protects citizen privacy and creates an enforcement avenue, but it may reproduce the inflexibility that limited eIDAS 1 adoption. If a business needs something working by tomorrow and state registration takes weeks, it will reach for a private wallet instead.
Truvera Positioning and Market Timing
- Truvera does not play in PID issuance (a government role) but positions across PID verification, QEAA issuance in partnership with a qTSP, EAA issuance and verification, and private wallet provision. Its wallets are already built to ARF standards and tested against the formats, so for many organizations the decision is not whether to build a wallet but how to white-label an existing one, closer to a configuration and branding exercise than a multi-year build. The slides list Truvera's wallet delivery options as embedded in app, cloud wallet, and white-label wallet, and its private-ecosystem credential formats as ED25519, anonymous, and ecosystem-bound.
- To create derivative credentials for private use cases, Truvera expects it will need to act as an intermediary and help customers verify the PID, then derive credentials from it. The exact per-jurisdiction registration requirements are still being researched.
- The European Business Wallet is a live area to watch. It is a proposal, not yet adopted law, published as COM(2025) 838 on 19 November 2025, and no Trusted List of Business Wallet Providers exists yet. It moves through the ordinary legislative procedure; as of early 2026 the Parliament rapporteur (Eero Heinaluoma, S&D) had published a draft report. The WE BUILD consortium of over 200 organizations across 28 countries is already piloting business and payment use cases such as proof of representation, mandates, and supply chain credentials. Agne expects business wallets may be adopted before personal ones because market demand is stronger.
- eIDAS 2 mandates no payment model, which appears deliberate: the regulation governs trust, interoperability, and privacy but leaves commercial terms to be worked out sector by sector. The speakers noted a structural gap: the verifier-pays-issuer model is hard to implement inside EUDI because the required unlinkability between issuer and verifier removes the mechanism for compensating issuers.
- On adoption, Richard predicted countries without an existing digital ID may adopt quickly, while countries with widely used schemes (Poland's mObywatel, Lithuania and its Smart-ID-style tools, Sweden, Italy) face a real switching problem. Agne noted Poland's national tooling already bundles 30 to 40 services, which weakens a citizen's incentive to move to a new state wallet.
- Italy is the notable outlier on private wallets holding state credentials. The slides cite the specific basis: Italian Law no. 56/2024, with implementing decrees still pending. Agne described Italy as the only country she could find that has written this into law.
- Several pieces of the ecosystem are still being finalized: the ENISA wallet certification scheme (draft in public review, final expected later this year), the ARF itself (currently v2.9.0, on an iterative cycle continuing through 2026), relying party registration processes (which vary by member state), and cross-border interoperability for issuer keys and revocation. The practical takeaway both speakers stressed: always check the date on anything you read about EUDI, because it moves week to week.
