Before a business can properly access EU Digital Identity Wallets, the question is not only technical.
It is also about registration.
Who is the Relying Party?
Where does it register?
Which data is it allowed to request?
Who needs an access certificate?
And what changes when a business works through an intermediary instead of connecting to wallets directly?
These are the questions we’re hearing more often from customers, partners, and teams preparing for wallet-based identity flows.
In this post, we answer the main questions around EUDIW Relying Party registration: where a Relying Party registers, when multiple registrations may be needed, how access and registration certificates work, and what changes when a business uses an intermediary like eID Easy.
Quick answers
Where does a Relying Party register for EUDIW?
A wallet Relying Party registers in the Member State where it is established. Regulation (EU) 2024/1183 says that where a relying party intends to rely on European Digital Identity Wallets for public or private digital services, it must register in the Member State where it is established.
Does a Relying Party need to register in multiple countries?
The basic model is registration in the Member State of establishment. But multiple registrations may become relevant if a group operates through separate national legal entities, if different entities hold different national regulated entitlements, or if different services and intended uses are tied to different country operations.
What is an access certificate?
A wallet-relying party access certificate authenticates and validates the wallet-relying party when it connects to a wallet.
What is a registration certificate?
A wallet-relying party registration certificate indicates which attributes the Relying Party has registered to request from users.
Does an intermediary need to register in every country where its customers are based?
No, not necessarily. Under the intermediary model, the intermediary has its own wallet-facing access certificate, while each intermediated Relying Party is registered in the Member State where that Relying Party is established. The intermediary may still need to interact with the Relying Party’s national Registrar as part of the registration relationship.
Does an intermediated Relying Party need its own access certificate?
No. Under the ARF model described in the draft, an intermediated Relying Party using an intermediary does not need its own wallet-facing access certificate. But it still needs to be registered, and the request should identify the underlying Relying Party and intended use.
Why this matters
A lot of EUDIW discussion focuses on wallet integration: APIs, protocols, wallet apps, credential formats, and technical standards.
That is only one part of the problem.
For Relying Parties, wallet access also depends on the trust and registration layer.
A business needs to understand:
- which legal entity is the Relying Party
- where that Relying Party must register
- which attributes it is allowed to request
- what intended use it must declare
- which certificates are needed
- how the wallet identifies the party requesting data
- how the user sees the request
- what role an intermediary can play
This is where the intermediary model becomes important.
eID Easy is building the eID Easy Wallet Hub to help Relying Parties interact with EUDI Wallets through an intermediary model. The Relying Party remains responsible for the service and the data it requests. eID Easy helps with the wallet-facing infrastructure, trust flow, and connection layer. The original draft frames eID Easy’s intended role as assisting Relying Party customers in interacting with digital wallets through the Wallet Hub.
The point is simple:
Relying Parties should not have to manage every wallet, certificate, registration path, and national implementation detail alone.
.png)
Key terms first
Relying Party
A Relying Party is the business, organisation, or public service that wants to rely on wallet data.
For example, this could be a bank, fintech, healthcare provider, telecom company, marketplace, platform, age-restricted service, or public authority.
The Relying Party is the organisation asking the user to share wallet data for a specific service or use case.
Registrar
A Registrar is the body responsible for maintaining the list of registered wallet-relying parties established in its territory.
In simple terms: this is the national registration body.
Access certificate
The access certificate helps the wallet authenticate and validate who is connecting to it.
In simple terms: it helps the wallet know who is technically making the request.
Registration certificate
The registration certificate indicates which attributes the Relying Party has registered to request from users.
In simple terms: it helps show what the Relying Party is registered to ask for.
Intermediary
An intermediary acts on behalf of Relying Parties in wallet interactions. eID Easy is an intermediary.
Regulation (EU) 2024/1183 states that intermediaries acting on behalf of relying parties are deemed to be relying parties and must not store data about the content of the transaction.
In simple terms: the intermediary can handle the wallet-facing interaction, but it is still part of the regulated trust flow.
1. Where does a Relying Party register?
The basic rule is clear:
A wallet Relying Party registers in the Member State where it is established.
The regulation also says that the Relying Party must provide information needed for authentication, contact details, intended use of the wallet, and the data it intends to request from users. It also says Relying Parties must not request data other than the data indicated in that registration.
This matters because registration is not just a formality.
It is part of how the wallet ecosystem controls who can ask for data, what they can ask for, and how that request is shown to the user.
2. When could multiple registrations be needed?
The default model is registration in the Member State of establishment.
But there are practical cases where more than one registration may be relevant.
.png)
Separate legal entities in different Member States
If a group operates through separate national legal entities, each entity may need to register where it is established.
For example, if the Belgian, French, and German entities are each the actual service provider for their local market, each may need its own registration with its national Registrar.
Different national regulated entitlements
Some wallet use cases depend on national authorisations.
This may apply to banks, healthcare providers, professional bodies, education providers, or other regulated services.
If different national entities hold different local entitlements, each entity may need to register separately so the relevant Registrar can see who is requesting data, for what purpose, and under which entitlement.
Different services or intended uses
A Relying Party may have several services with different intended uses.
Each service may require a different set of attributes. In some cases, this may mean more than one registration certificate.
If those services are operated by different legal entities in different countries, the registration model becomes more country-specific.
National readiness differences
Member States are not all moving at the same speed.
Some may have wallets in production before the full EUDIW certification and cross-border registration model is mature. Some may open registration earlier than others. Some may have more detailed or more demanding registration processes.
This could create practical differences in how quickly organisations can access wallets in different countries.
3. Why use an intermediary?
A Relying Party can try to connect to wallets directly.
But direct wallet access means taking on more than API work.
It means dealing with:
- wallet-facing technical integration
- access certificates
- registration certificates
- national Registrars
- intended-use declarations
- attribute lists
- wallet-specific implementation differences
- changes in national procedures
- the relationship between the technical wallet request and the underlying Relying Party
An intermediary exists to reduce that burden.
Under the ARF discussion model, an intermediary registers as a Relying Party and obtains an access certificate containing its own name and identifier. For each end Relying Party using its services, the intermediary holds a registration certificate for the registered intended use of that end Relying Party. When requesting attributes on behalf of that end Relying Party, the intermediary uses its own access certificate and the registration certificate related to the end Relying Party and intended use.
That is the model eID Easy is building toward with the Wallet Hub.
The commercial point is not complicated:
You bring the use case.
eID Easy helps with the wallet access layer.
4. Does an intermediary need to register in the country of every Relying Party it supports?
No, not as a separate Relying Party in every country.
The intermediary registers once as a Relying Party with a Registrar and obtains access certificates in its own name. Separately, each intermediated Relying Party is registered in the Member State where that Relying Party is established.
So the intermediary may need to interact with different national Registrars, but that does not automatically mean it must create a separate local Relying Party registration in every country.
The practical work is still important.
The intermediary may need to provide evidence to the Registrar that the intermediated Relying Party uses its services. The registration record should show the relationship between the two parties.
5. What does the wallet show the user in an intermediated flow?
In an intermediated flow, transparency matters.
The wallet should be able to identify both:
- the intermediary handling the wallet-facing interaction
- the underlying Relying Party requesting the data
The ARF discussion says that if a wallet receives a request from an intermediary on behalf of a Relying Party, the wallet should verify the intermediary and display the name of the intermediary to the user. It also says that if verification succeeds, the wallet should display the names of both the intermediary and the intermediated end Relying Party.
This is important for user trust.
The user should understand who is technically handling the request and who will actually use the data.
6. Does an intermediated Relying Party need its own access certificate?
No.
An intermediated Relying Party can rely on the intermediary’s access certificate for the wallet-facing interaction.
But that does not make the Relying Party invisible.
The intermediated Relying Party still needs to be registered. The intermediary registers the Relying Party, including the attributes that Relying Party wants to request for each intended use.
So the simple version is:
The intermediary handles the wallet-facing access certificate.
The Relying Party still needs to be registered for the data it wants to request.
7. What does this mean for businesses preparing for EUDIW?
For businesses, EUDIW registration is not only a compliance detail and not only a technical integration.
It sits between both.
Before production wallet access becomes urgent, Relying Parties should map:
- which legal entity provides the service
- which country that entity is established in
- what wallet data is actually needed
- which attributes are needed for each use case
- whether the use case depends on a national authorisation
- whether they want direct wallet access or an intermediary model
- which fallback identity methods are needed while wallet adoption grows
This is where eID Easy can help.
eID Easy already aggregates national eIDs, Bank IDs, and digital signature services through one integration. As EUDIW develops, we are building the Wallet Hub to help Relying Parties interact with digital wallets through an intermediary model.
That means helping businesses:
- understand where and how they may need to register
- define which wallet attributes they actually need
- prepare for access and registration certificate flows
- connect to wallets through one wallet-facing infrastructure layer
- keep the underlying Relying Party visible in the flow
- avoid managing every national wallet implementation alone
The Relying Party stays responsible for the service, the legal basis, and the data it requests.
eID Easy helps make wallet access manageable.
.png)
Final takeaway
EUDIW registration is not just admin.
It is part of the wallet trust layer.
Relying Parties need to know where they register, what data they are allowed to request, which certificates are involved, and how the user sees the request.
Intermediaries matter because they can reduce the wallet-facing burden while keeping the underlying Relying Party registered and visible.
That is the role eID Easy is building for with the Wallet Hub.
Need to understand how your business could access EUDI Wallets through an intermediary? Drop us a message.
