In the first session, we covered the basics: what EU Digital Identity Wallets are, what they can be used for, when they are coming, and who is likely to be affected. In S01E02, the goal was different. This time, we used available wallet sandboxes to show how wallet flows work in practice, and why this is not one clean integration across Europe.
The session was moderated by John Jolliffe, Provider Relationship Manager at eID Easy, with live demos from Andrii Hrynchuk, Senior Developer at eID Easy.
In this post
We’ll recap what was covered in the session:
- why EUDIW is not one single wallet integration
- what a relying party flow looks like
- what users see inside the wallet
- how OAuth and QR code flows work
- what PID, age verification, and mobile driver’s licence can look like in practice
- why wallet sandboxes behave differently
- what this means for relying parties preparing for EUDIW
EUDIW is a federation, not one central wallet
One of the most important points from the session was simple:
The European Digital Identity Wallet is not one centrally operated wallet.
It is a federated model. There is a common legal framework, common technical direction, and shared rulebooks, but each Member State is still building and operating its own national wallet solution. That means national wallet projects are expected to interoperate at EU level, but they are not internally identical.
That distinction matters.
A relying party should not expect every wallet sandbox to behave the same way, support the same flows, expose the same credentials, or use the same technical setup today. Some countries are testing through public sandboxes. Some are working through closed pilots. Others are simply not as far along yet.
This is exactly why aggregator and intermediary layers matter.
eID Easy already aggregates eID methods and digital signature services. With eIDAS 2.0 and EUDIW approaching, the same logic applies: relying parties should not have to understand and maintain every national wallet integration separately.
What does a relying party flow look like?
In a wallet flow, the user holds digital credentials in their wallet and decides what data to share.
Andrii walked through the main roles in the flow:
The user controls the wallet and decides what to share.
The wallet stores and presents credentials, with user consent.
The verifier requests, receives, and validates data from the wallet. In this session, that role was played by eID Easy.
The relying party is the company or service that needs the data, such as a bank, pharmacy, platform, onboarding flow, or regulated service.
The important point for relying parties is this:
You are not just “adding a wallet”. You are requesting specific claims from a wallet, through a trust flow, and receiving structured identity data back.
That is where things become practical.
What the user sees inside the wallet
The live demo showed how different wallets can present credentials in different ways.
In the German wallet sandbox, Andrii showed a personal ID credential displayed inside a still-developing wallet interface. The credential contained personal data fields that could be shared when requested by a relying party.
In the Namirial private wallet, the credential list looked different. The interface showed more technical information, including credential formats that are useful for developers, but not something end users should have to care about in production.
In the French wallet flow, Andrii showed how credentials could be added and presented, including a flow where the wallet application had recently changed and the test setup had only started working again shortly before the session. That was a useful reminder: wallet environments are evolving quickly, and what works one day may change the next.
For relying parties, this matters because user experience will not be identical across every wallet. The end result may be similar — a user shares trusted data — but the wallet interface, approval steps, and technical behaviour can differ.
OAuth redirect flow vs QR code flow
The session also covered two ways a wallet flow can be started:
OAuth redirect flow
This is closer to a familiar authentication-style redirect. The user is sent into the wallet flow and then returned.
QR code flow
The relying party shows a QR code. The user scans it with a wallet, reviews the request, approves sharing, and the relying party receives the returned claims.
Andrii explained that the QR code flow may often feel more natural for relying parties because it gives more control over how the QR code, context, and surrounding text are displayed in the relying party’s own interface.
For product and UX teams, this is one of the key practical decisions: how do you want users to enter the wallet flow, and how much control do you need over the screen around it?
What data can come back?
The session focused on three credential types that can already be tested in the eID Easy EUDIW Playground:
PID
The core identity data used to identify a person.
Age verification
A more privacy-friendly way to answer a specific question, such as “is this person over 18?”, without sharing unnecessary identity data.
Mobile driver’s licence
A digital driving licence credential that can also be used for certain identity-related flows, depending on the use case.
Andrii showed that age verification can work as a separate claim. Instead of requesting a full PID with name, document number, birth date, and other details, a relying party can ask only whether the user is over a certain age. In the demo, the response came back as a simple true/false value.
That is an important shift.
With wallet-based identity, relying parties should not think only in terms of “getting identity data”. They should think in terms of asking for the minimum claims needed for the use case.
Sometimes that may be full identity data. Sometimes it may only be age verification. Sometimes it may be a licence, diploma, employee credential, prescription, membership, or another attestation. The list of possible wallet credentials is expected to grow over time.
What happens behind the scenes?
From the user’s point of view, the flow can look simple:
Scan. Review. Approve. Done.
Behind the scenes, more is happening.
The relying party starts the journey by connecting to the verifier. The verifier generates the QR code or starts the transaction. The wallet scans the request, fetches the request details, shows the user what is being requested, and sends the response back after approval. The verifier then checks the data, validates issuer certificates, matches the response to the original transaction, and returns the data to the relying party.
That verifier layer is where a lot of the hard work sits.
It needs to understand wallet behaviour, credential formats, trust details, returned claims, and failures. Ideally, most of that complexity should stay invisible to end users and relying parties. John made that point clearly: the technical flow is interesting to developers and implementers, but end users should mostly just care that they can access the service they are trying to use.
Why wallet sandboxes behave differently
A big part of the session was showing that wallet sandboxes are not all the same.
Today, different wallet environments may differ in:
- how users start the flow
- whether the wallet uses deep links or an internal scan button
- what credential formats are supported
- what request formats are expected
- how relying parties are identified
- whether certificates are required
- how much technical information is exposed
- what claims can be returned
- how stable the test application is
That is not necessarily a bad thing. It reflects the fact that national projects are at different stages, and many teams are still testing their wallet architecture, trust model, credential formats, and user experience.
But it does create work for relying parties.
A company that wants to integrate directly with each wallet will need to understand those differences, track changes, handle breaking updates, and maintain country-by-country implementation details.
This is exactly the type of complexity eID Easy is working to abstract away.
What should relying parties do now?
The session was not about panic.
It was about preparation.
The final EUDIW ecosystem is still developing. Some national wallets already exist in production, but they may not yet be certified as full EUDI wallets. Other countries are still in sandbox, pilot, or earlier development phases. In the Q&A, John noted that countries such as Denmark, France, and Italy are likely to be among the earlier movers because they already have live wallet initiatives, while the wider certification and relying party registration infrastructure still needs to mature.
For relying parties, the practical question is not only:
“When will EUDIW be ready?”
A better question is:
“What do we need to understand now, so we are not starting from zero later?”
That means looking at:
- which identity or attribute claims your business actually needs
- where wallet-based identity could reduce friction
- how wallet flows fit into onboarding, KYC, login, age checks, or regulated access
- whether you want to integrate directly with wallets or through a hub
- what fallback methods you need while wallet adoption grows
One point from the Q&A was especially important: EUDIW is not replacing existing identity providers overnight. In case of wallet issues or breaking changes, current eIDAS 1 identity providers such as Evrotrust, itsme, ID cards, and other existing methods may still be part of the fallback picture.
FAQ from the session
1. Which EU Member State will release a fully functional EUDI wallet first?
It is difficult to say precisely because Member States are moving in different ways. In the Q&A, John pointed to countries such as Denmark, France, and Italy as likely early candidates, because they already have live wallet initiatives that may later be certified as EUDI wallets once the relevant certification and relying party registration systems are in place.
2. Are business wallets the same as citizen EUDI wallets?
No. The Q&A made a distinction between the citizen EUDI wallet and the upcoming European Business Wallet discussion. The citizen wallet is focused on natural persons and user-controlled identity data, while the Business Wallet is expected to focus more on organisational users, access controls, delegation, automation, and enterprise system integration.
3. Can wallets support delegation or representation?
Yes, this is part of the wider wallet discussion. The Q&A noted that Annex VI of the EUDI regulation includes attributes related to powers and mandates to represent natural or legal persons. That means a user should be able to present their PID and an attestation supporting the characteristic or authority they need to prove.
4. What happens if a user does not share all requested PID fields?
It depends on whether the claims are mandatory or optional. According to Andrii’s answer in the Q&A, if all requested claims are mandatory, the user can only accept or decline the transaction. If optional claims are used and the user does not provide them, the verifier receives empty values.
5. Will EUDIW also support e-signing flows?
This was not shown in the session, but it is part of the direction. The Q&A explained that eID Easy started as an aggregator of e-signature and eID services, and plans to continue aggregating remote signing services with QTSPs as part of its wallet offering.
6. Does eID Easy store user data?
In the Q&A, Andrii explained that as an intermediary, eID Easy deletes user data after transferring it to the relying party, but cannot guarantee how the relying party treats the data. He also noted that actor-specific certificates should help with accountability in case of a data leak.
7. Can only the relying party decrypt user data?
Not currently. The Q&A notes that BYOK is not implemented today, but was raised as a good point for further discussion and would likely require additional development.
Final takeaway
EUDIW will not arrive as one identical wallet integration across Europe.
The regulation sets the direction, but the practical reality is still wallet-by-wallet, country-by-country, and sandbox-by-sandbox. That is exactly why relying parties should start testing now: not because everything is production-ready, but because the integration patterns, user flows, claims, and trust questions are already becoming visible.
The good news is that you do not need to figure it all out alone.
The eID Easy EUDIW Playground gives teams a way to see wallet flows in action today, test what comes back, understand where the differences are, and prepare for wallet-based identity without building every integration from scratch.
Want to test real EUDIW wallet flows?
