In our third live session on European Digital Identity Wallets, we moved one step further into the practical side of wallet adoption.

In Episode 1, we covered the basics: what EUDIW is, when it is coming, and how it may affect businesses. In Episode 2, we looked behind the scenes at real wallet flows in the eID Easy Wallet Playground.

This time, we focused on the questions that come before a relying party starts an integration:

→ Who is actually requesting the customer’s information?
→ Where does that business register?
→ What changes when an intermediary handles the wallet interaction on your behalf?

Because wallet readiness does not start with an API call.

It starts with understanding your service, your legal entity, your data request, and your role in the wallet ecosystem.

→ Watch the full recording here

First, what is a relying party?

A relying party is the organisation requesting wallet data in order to provide a service.

That could be a company asking someone to prove their identity, confirm their age, authenticate into a service, or share another verified attribute from their wallet.

So in a wallet flow, the user controls the wallet. The relying party is the organisation that needs specific information from that user in order to provide the service.

This is already a shift from how many businesses think about identity today.

It is not just “the user proves something.”
The organisation asking for the data also has to be clear about who it is, what it is asking for, and why.

From the user’s point of view, the question is simple:

Who are you, and why do you need this information?

That question should be understandable in the wallet flow itself.

Where does a relying party register?

One of the big differences between today’s national eID methods and the upcoming EUDI Wallet ecosystem is that relying parties need to register before they can access data from a user’s wallet.

This registration is a deliberate part of the trust framework. It helps identify the organisation requesting wallet data, its intended use, and the attributes it plans to request.

The basic rule is straightforward:

A relying party registers in the Member State where it has its registered office.

Once registered, the relying party should be able to request attributes from users with wallets across Europe.

But, as always, the real world adds some complexity.

There are situations where a relying party may need more than one registration. For example, the same legal entity may have different services or use cases that require different wallet data. Or a group may operate through separate legal entities in different Member States, with each entity providing its own services.

So the starting point should not be:

"Where are our customers?"

It should be:

"Which legal entity provides this service, and what is it asking the customer to prove?"

A shared brand does not always mean one relying party registration.

Do not ask for everything just because the wallet can provide it

Registration is not just a company identification exercise.

A relying party also needs to declare its intended use and the information it plans to request. The idea is that the relying party should only request the attributes needed for that specific interaction.

A simple example is age verification.

If the business only needs to know whether someone is over 18, it should not automatically ask for the user’s full identity details, exact date of birth, address, or anything else that is not needed for that decision.

An age-check journey and a full customer onboarding journey should not have the same data request by default.

The better approach is:

Start with the decision your business needs to make.
Then work backwards to the information needed for that decision.

That may involve product, legal, compliance, and technical teams. This is why an internal workshop before implementation can be useful: each wallet use case may have different data requirements, responsibilities, and user expectations.

Registration is not authorisation

Another important point from the session:

Registering an intended use does not automatically mean you are legally entitled to process the information.

The ARF separates registration from any authorisation that may be required to request particular attributes. Businesses still need to understand their legal basis for asking for the data, including under GDPR Article 6.

This matters because companies may be tempted to make their registration request very broad, covering every possible future use case in one go.

That might sound efficient, but it can create problems.

A user could be presented with a long list of requested attributes that does not make sense for the journey they are in. That can damage trust. Broad requests may also attract scrutiny from data protection authorities later on.

So instead of asking for everything, start with the use case.

What decision does the service need to make?
What information is actually needed?
Can the user understand why they are being asked for it?

That is where wallet readiness really starts.

Registration certificates and access certificates do different jobs

The session also covered two important terms in the wallet ecosystem:

Registration certificates and access certificates.

A registration certificate is essentially the official record of who the relying party is, what service or use case it has registered for, and which data attributes it intends to process. It can also declare whether the relying party intends to access certificates through an intermediary.

An access certificate is used when the relying party, or an intermediary acting on its behalf, actually connects to the wallet.

A simple way to think about it:

Registration certificate: what is this organisation registered to request?
Access certificate: who is connecting to the wallet?

Two certificates. Two different jobs.

What changes when an intermediary is involved?

Most relying parties will not want to build and maintain direct integrations with every wallet ecosystem themselves.

That is where an intermediary can help.

A relying party intermediary performs the wallet interaction on behalf of the relying party. The interaction is still based on the same controls that would normally apply between a relying party and a wallet, but the intermediary appears as an additional party brokering the interaction.

In this model, the intermediary is itself registered as a relying party. When the intermediary handles the wallet transaction, it is technically the party connecting to the wallet on behalf of the underlying relying party. It uses its access certificate to authenticate itself during that interaction.

This means the downstream relying party does not need to hold its own access certificate for that intermediated flow.

But the complexity does not disappear.

The intermediary still needs to request access certificates for the intended use cases of its relying party customers. In the example from the session, if an intermediary has 10 customers, each with 10 different attribute requests, that could mean managing 100 access certificates.

So for the business, it may feel like one integration.

Behind the scenes, someone still has to manage registration flows, certificate structures, national authorities, technical instances, and wallet implementation differences.

That is the value of the intermediary model: simplifying access without pretending the operational work does not exist.

How can an intermediary support relying party registration?

An intermediary like eID Easy can help relying parties prepare for registration in the Member State where they are established.

That means helping them prepare the required information about their organisation, service, intended use, and requested attributes.

The challenge is that many national registration processes and registries are still being set up.

So there is still uncertainty around what different registries will require, how national processes will work, and how quickly the infrastructure will become available.

Once the relying party is registered and has its registration certificate, the intermediary can use that information to request access certificates where needed, and manage the interaction with wallet units on the relying party’s behalf.

This is why relying parties should not wait until everything is “finished” before they start preparing.

A lot can already be clarified now:

→ Which entity provides the service?
→ Which customer journey matters first?
→ Which information does that journey actually need?
→ Who is responsible for registration, technical connection, and ongoing changes?

What does the end user see?

The user experience matters.

In a wallet flow operated by an intermediary on behalf of a relying party, the approval screen should show the name of the intermediated service. The intermediary’s details are recorded in the wallet transaction log rather than being displayed as the main name on the approval screen.

The principle is not to make the intermediary untraceable.

It is to keep the immediate request understandable.

From a product perspective, the user should recognise the organisation asking for information and understand why the request is happening.

If the user looks at the wallet screen and thinks, “I have no idea who this company is or why it wants these details,” that is a problem worth finding before launch.

What should businesses do next?

The most practical recommendation from the session was simple:

Start with one customer journey.

Not every possible wallet use case.
Not every country.
Not every attribute the wallet may eventually support.

Start with one journey that matters.

Your first working session should produce a one-page description of that journey:

• Which legal entity provides the service?
• What decision does the business need to make?
• What information is needed for that decision?
• Who handles registration?
• Who handles the technical connection?
• Who owns ongoing changes?
• What happens if the data is unavailable?
• What happens if the user declines?

This gives the business, legal, product, and technical teams something concrete to work with. It also helps prepare the right registration certificate requests and makes it easier to stay aligned with the obligations that will apply.

Where eID Easy’s Wallet Hub fits in

eID Easy is building the Wallet Hub to support relying parties through an intermediary model.

The idea is to help businesses manage wallet access, registration, and certificate flows without having to tackle every national implementation independently.

That means the conversation starts with the service:

What does your service do?
What do you need to establish about the customer?
Which claims do you actually need?

It should not start with:

How can we obtain everything the wallet contains?

A well-defined use case gives everyone something concrete to work with.

The reality today: still national, still moving

The long-term direction is EU-wide interoperability.

But right now, the practical reality is still national.

Member States are developing national wallets, certification schemes, registries, and registration policies. Once wallets are certified at national level, they still need certification against the EU-level certification scheme, which is also still under development.

That means we should expect a period of parallel implementations, different registry structures, and wallet-like services becoming available in phases.

The session included examples such as France, Denmark, Norway, Ireland, and Switzerland, each with different access, registry, or local requirement considerations.

So the better question is not only:

"When will EUDIW be ready?"

It is also:

"What do we need to understand now, so we are not starting from zero later?"

Main takeaways

Wallet readiness starts before the integration.

For most organisations, this will not be a one-and-done technical task. Businesses need to understand which organisation is asking, why it is asking, what it is registered to request, and whether the customer can understand the request.

The key takeaways:

1. Know who is asking.
Identify the legal entity providing the service.

2. Know why it is asking.
Start with the business decision and work backwards to the information needed.

3. Do not ask for everything.
Different journeys need different data requests.

4. Understand registration and certificates.
Registration certificates and access certificates serve different purposes.

5. Be clear about the intermediary role.
An intermediary can simplify access, but responsibilities still need to be explicit.

6. Test the user experience.
The user should understand who is asking for data and why.

7. Start with one journey.
A clear, practical use case is the best place to begin.

Q&A

Is the national relying party registration infrastructure still unavailable?

In many cases, yes. The registration infrastructure is still being built.

Each country needs to set up or appoint the body that will act as registrar, along with the technical authorities responsible for certification and access certificates. Countries are moving at different speeds, so the process will not look the same everywhere at first.

Does this mean countries will not meet the December 2026 timeline for wallet availability and registration?

Not for full availability.

Some countries may have testing environments, early wallet versions, or pre-certified services available by then. But full, meaningful production availability across Europe will likely come in phases.

So December 2026 should not be understood as “everything is fully live everywhere.”

What requirements apply to private wallets?

Private wallets can still have their own relying party processes and registries, but they are not necessarily certified or regulated in the same way as government-backed EUDI Wallets.

That means private wallets may be useful for some use cases, but not suitable for others where a higher level of government-backed certification, regulation, or oversight is required.

Will the citizen see the intermediary name, the relying party name, or both?

The user-facing approval screen should show the underlying relying party or service name — the organisation the user actually recognises in that journey.

The intermediary is not meant to disappear, but its details are recorded in the wallet transaction log rather than being the main name shown on the approval screen.

The point is to keep the request understandable for the user: who is asking for my data, and why?

Will a QTSP issue registration or access certificates?

The live answer was that these certificates sit inside the trust framework, so QTSPs are expected to play a role.

However, not every QTSP will automatically be able to issue registration or access certificates. The key question is which QTSPs will be mandated or authorised within each government-certified scheme.

So yes, QTSPs are part of the picture — but it will likely be a controlled role, not open to any QTSP by default.

How can intermediaries work around the identity data storage limitation?

The short answer is: they do not work around it by storing the data.

An intermediary can broker the wallet interaction and pass the information to the relying party, but it cannot retain or reuse the data exchanged during the transaction.

The relying party, as the service entity, remains responsible for the service, the legal basis, and any evidence or customer information it needs to retain. The intermediary helps with access and orchestration, but it does not become a parallel KYC data store.

Watch the full session

This recap covers the main points, but the full discussion goes deeper into relying party registration, intermediary responsibilities, certificates, user-facing wallet flows, and what businesses should start preparing now.

Watch the full recording here: [Full recording link]

Want to talk through your own wallet use case?

If your team is starting to think about EUDIW, relying party registration, wallet access, or how wallets could fit into your customer flows, start with one concrete journey.

Then talk to us.

We can help you figure out what your service needs, which claims matter, and how wallet access could work through the eID Easy Wallet Hub.