EU Digital Identity Wallets are moving from “interesting regulation topic” to “something businesses need to actually prepare for.”
That was the reason behind our first Explained by eID Easy live session:
Explained by eID Easy — S01E01: EUDIW Made Easy
The goal was simple: explain what EUDIW means for businesses in simple English.
We covered what’s changing under eIDAS 2.0, who may become a relying party, what compliance teams need to understand, what technical teams should prepare for, and what businesses can already start testing through eID Easy’s wallet sandbox.
And judging by the questions, this topic is very much not “future noise.” It is already on people’s minds.
Why this session mattered
The European Digital Identity framework is changing how identity, attributes, authentication, and trust services will work across Europe. Regulation (EU) 2024/1183 is now in force, and the European Commission says Member States must provide EU Digital Identity Wallets to citizens by the end of 2026. The Commission also describes the wallet as optional for users, available to EU citizens, residents, and businesses, and designed to support secure authentication across the EU.
For businesses, the practical question is not just:
“What is an EUDI Wallet?”
It is:
“What does this mean for our onboarding, authentication, compliance, signatures, data requests, and customer experience?”
That is where things get interesting.
What we covered
The session was moderated by Joao Rei, Co-founder and CBDO at eID Easy, with input from:
John Jolliffe, Provider Relations at eID Easy
Andrea Feliziani, Chief Compliance Officer at eID Easy
Mats-Joonas Kulla, Co-founder and CTO at eID Easy
The session followed three angles: business context, compliance, and technical implementation.
1. eIDAS 1 vs eIDAS 2: what actually changes?
John opened with the big picture.
Under eIDAS 1, Member States had the freedom to build and notify their own electronic identity systems. Under eIDAS 2, EU countries are required to provide citizens with a Digital Identity Wallet. That changes the landscape from fragmented national eID schemes to a more common wallet-based layer.
The main shifts discussed were:
- from voluntary national eID schemes to mandatory wallets
- from separate login flows to a common user-facing wallet layer
- from identity data to verified attributes
- from mostly public-sector use to private-sector acceptance
- from aggregators to more regulated intermediaries
- from “can we verify this person?” to “what verified proof do we actually need?”
That last point matters a lot.
EUDIW is not only about proving someone’s full identity. It introduces the idea of sharing specific, verifiable attributes, for example age, driving entitlement, education credentials, or proof of representation, instead of always sharing a full identity document.
In other words: the wallet is not just another login button.
2. What the EUDI Wallet is; and what it is not
The wallet can be thought of as an app where citizens and businesses can store, manage, and share digital identity credentials across Member States. But it is not just a private-sector “Big Tech wallet” with a new label.
The session made this distinction clear: EUDIW is part of a regulated trust framework, with rules around who can issue wallets, who can issue credentials into wallets, who can request data from wallets, and how that interaction is certified and controlled.
The wallet is also designed around user control. A service should not automatically receive “everything in the wallet.” It requests specific data or attributes, the user sees what is being requested and by whom, and the user approves what to share. MJ’s technical notes also emphasized this point: in many cases, a business may not need a full identity document at all: only a verified fact, such as “this person is over 18” or “this person has a valid driving entitlement.”
"That is a very different model from traditional document scanning."
3. The big new business term: relying party
Andrea then took us into the compliance side.
A relying party is, in practical terms, a service provider that requests and receives user attributes from a Wallet Unit. The session focused on relying parties as businesses or services interacting with wallets to request and receive user attributes.
This is one of the concepts businesses need to understand early.
A relying party will need to think about:
- what attributes it wants to request
- why it needs those attributes
- whether the request is within its registered scope
- how it is authenticated by the wallet
- what certificates or registration processes may apply
- whether it connects directly or through an intermediary
Andrea also covered the trust framework around relying parties: registrars, access certificate authorities, registration certificates, access certificates, and intermediaries. The short version: wallet access is not just a technical integration. It is also a controlled trust relationship.
4. Why 27+ wallets matter
One of the strongest business takeaways was this:
There will not be one single EU wallet implementation that makes everything magically simple.
National EUDI Wallet projects are being developed by Member States within a common framework, but credential sources, schemas, languages, terminology, and administrative structures may still differ. For example, “surname,” “family name,” and “last name” may represent the same concept but appear differently across systems. Address formats may also vary significantly.
That creates a practical challenge for businesses.
If a company wants to interact with wallet holders across Europe, it may need to deal with many wallets, many issuers, many attribute formats, and many national differences.
This is where intermediaries and harmonisation become important.
The session positioned eID Easy’s role as helping businesses avoid country-by-country wallet complexity by providing a more unified access layer across a multi-wallet Europe.
5. The technical side: sandbox, OIDC-style flows, and Wallet Hub
MJ closed the main section with the technical angle.
For businesses, the good news is that wallet access does not need to mean rebuilding your entire identity stack from scratch.
In the session, MJ explained that eID Easy is working on wallet access through familiar OIDC-style flows. In the sandbox, customers can already test wallet connection and attribute-request flows. In production, the exact technical parameters are still evolving, but the direction is clear: make wallet access easier for customer systems that already understand standard OpenID Connect-style integration.
MJ also introduced what eID Easy is building with the Wallet Hub.
The problem: EUDI Wallets introduce strong, government-backed identity data, but the protocols are new — including OID4VP, SD-JWT, mdoc, trust lists, and wallet callbacks. Most customer systems still expect standard OpenID Connect.
→ The Wallet Hub is designed as the bridge between those worlds: customers integrate once using a familiar OIDC-style approach, while eID Easy handles wallet presentation, verification, trust validation, and mapping into standard OIDC Identity Assurance claims.
In plain English: less wallet-protocol headache for businesses.
Q&A highlights from the session
The Q&A was where things got especially practical. Here are some of the questions that came up, and what we covered.
1. Will there be one EUDI Wallet per country?
Not necessarily.
Some countries may issue a single government wallet. Others may take more of an ecosystem approach, where private-sector wallets can also be offered and endorsed under national rules.
The important point: businesses should not plan for “one EU wallet.” They should plan for a multi-wallet environment, with different national approaches, different credential sources, and potentially different wallet types for different use cases.
2. What is PID, and can it replace a national ID?
PID stands for Personal Identification Data.
It is the identity data embedded in the wallet and linked to the wallet holder, such as full name, date of birth, place of birth, nationality, and a unique identifier.
But PID does not replace national ID documents. Because wallet use is voluntary, PID, national ID documents, and existing electronic identification methods will coexist.
3. Will different country wallets have different attributes?
Yes.
There should be core PID attributes that appear across national wallets, but Member States may also add optional attributes. That means wallets may not all expose the exact same data in the exact same way.
For businesses, this matters because the same attribute request may work in one wallet but not in another.
4. What happens if a requested attribute does not exist in the user’s wallet?
Technically, the request can fail.
The exact behaviour depends on how the integration is designed. A business may decide that the whole flow should fail if one attribute is missing, or it may accept a partial response and continue with the attributes that are available.
This is why relying parties need to think carefully about which attributes are truly required and which are optional.
5. Can users add missing attributes themselves?
Not in a way that others will automatically trust.
A user may technically be able to create or add some kind of credential in certain contexts, but the real question is whether anyone will trust it. A self-issued or weakly verified attribute will not carry the same trust as a credential issued by a government, QTSP, or another trusted source.
As MJ put it during the session: it is a bit like issuing yourself a passport. The important part is not only whether a credential exists, but who issued it and why it should be trusted.
6. Is an intermediary registered differently from a relying party?
The exact country-level processes are still being built out.
The working view discussed in the session was that an intermediary is still a type of relying party. The difference is not necessarily in the basic registration concept, but in how the intermediary acts on behalf of its clients and how it handles the information.
This is one of the areas where national implementation details will matter.
7. Do intermediary clients need approval for each use case?
Potentially, yes — at least at the level of scope.
Access certificates include scope, and different use cases may require different scopes. A relying party that asks for a very broad set of attributes may create more friction and more scrutiny from the user.
The practical takeaway: define your use cases clearly before registering or requesting access. What data do you need? For what purpose? Is it required, or just nice to have?
8. Does a relying party need to register in every EU Member State?
Not necessarily.
The answer discussed in the session was that a relying party registers in the Member State where it is established. However, there may be practical or commercial reasons to register separately in another country, for example if different local entities, products, services, or use cases are involved.
So the simple answer is: one registration may be enough in principle, but the real answer depends on business structure, use case, and national implementation.
9. Can a wallet hold proof that someone represents a company or another person?
Yes, this is a likely and useful use case.
For example, a wallet could hold a credential showing that a person is allowed to represent a company or act within a defined scope.
Again, trust is the key issue. A government-issued or QTSP-supported credential is much easier for another party to trust. If a private company issues the credential, the relying party needs to trust that company’s process.
10. Will existing eID Easy clients get access to wallets?
eID Easy wants existing customers to be among the first to adopt wallet flows.
The transition path will depend on the customer’s commercial package and use case, but eID Easy has already made a sandbox environment available and is opening it up to existing customers.
Because the Wallet Hub is being built now, customers testing real use cases also have an opportunity to help shape how those flows develop.
11. What about micro and small companies?
The session notes covered that micro and small enterprises are currently carved out from the December 2027 acceptance obligation.
That exception comes from eIDAS 2 itself, so changing it would likely require a future regulatory amendment. For now, the more useful question for smaller companies may not be “do we have to?” but “where would wallet integration actually help us?”
Questions we’re still continuing inside the community
Some questions deserve more follow-up than we had time for live, including:
- reference implementations for relying party access APIs
- long-term provability of received attributes
- cost of integrating EUDIW into signing flows
- revocation processes for wallet attributes
- how wallet attribute standardisation will work for AML use cases
We’ll continue those conversations inside Digital Identity Exchange powered by eID Easy, where members can access the recording, deck, demo materials, and follow-up discussion.
The real takeaway
The overall message from S01E01 was to start mapping your use cases now.
Ask:
- What identity or attribute data do we actually need?
- Are we likely to be a relying party?
- Which sectors or services in our business may be affected first?
- Do we need full identity, or only a verified fact?
- How will wallet acceptance sit alongside current eIDs, BankIDs, signatures, and document verification?
- What can we already test before production rollout?
Wallets will not replace everything overnight. Existing eIDs, BankIDs, document verification, and signature methods will continue to matter. But EUDIW will introduce a new regulated channel for identity and attribute sharing, and businesses that prepare early will have a much easier time when adoption starts moving faster.
Missed the session?
The recording is available inside Digital Identity Exchange powered by eID Easy.
Community members can access:
- the full session recording
- the PDF deck from the session
- the French EUDIW sandbox demo
- the German EUDIW sandbox demo
- follow-up answers to unanswered Q&A
- future Explained by eID Easy episodes
Digital Identity Exchange is a free community for people who build, regulate, provide, or use digital identity. It is a place for practical conversations around eIDs, eSignatures, EUDIW, eIDAS 2.0, onboarding, compliance, wallets, trust services, and everything happening around digital identity. The community was created as a neutral, open space for users, providers, policymakers, builders, and curious experts to exchange ideas and questions.
And yes, Episode 2 is coming.
We will continue the conversation inside the community, including the questions we did not have time to answer live.
