Topic X - Relying Party registration

[phin10]

Welcome to the discussion on the Relying Party registration, part of the ongoing development of the Architecture and Reference Framework (ARF) for the European Digital Identity (EUDI) Wallet.

This discussion is based on the document.

This topic is to gather High level Requirements (HLR) for Relying Party registration. The HLR relate to information necessary for authentication to access European Digital Identity Wallets, and to relying parties’ contact details and their intended use of wallets, including what data relying parties may ask users for.

Items discussed in the paper:

• Proximity use case support
• Registration certificate per intended use
• Addressing the PID Providers and Attestation Providers on RPRCs
• Registration certificate for intermediaries
• Registration Suspension and Cancellation

This discussion is part of a structured process to refine and complete the ARF, with your input playing a vital role. We invite you to share your comments, insights, and suggestions here. Your contributions will be carefully reviewed and considered as we work towards the next version of the ARF, which will incorporate updates on this topic.

Thank you for participating in this important conversation.

[alex-reit]

Thanks for opening the conversation.

I think we can all agree that a Relying Party (RP) needs to register for the specific use case it intends to offer, the type of service it provides, and the data it requires to operate. However, let's consider the regulatory differences across EU member states...

If an RP is registered and approved by a regulator in one country, would this automatically grant it recognition across all EU states, or could there be cases where another national regulator requires suspension due to differences in local laws or policies?

How do we handle cross-border regulatory conflicts?
What mechanisms should be in place to manage suspension or re-registration across jurisdictions?

Looking forward to hearing your thoughts!

[sgmouy]

I personally regret the registration requirement that uniquely applies to EUDI wallets (all other eIDAS eID schemes are exempted) and goes way beyond what GDPR imagined - I am not aware of any other situation where a party receiving personal data has to inform public authorities of its intended use of these before receiving those. That's no doubt a personal opinion but as I am focusing on the payment use case of EUDI wallets. I wonder how this is going to apply for SCA (Strong Customer Authentication) purposes, i.e. when the wallet is used to authorized payments as per article 5f2 of eIDAS. One has to bear in mind that the relying party is not acting voluntarily but is forced to accept EUDI wallet SCA. Are we then expecting all payee merchants to register with their home authorities, just for the pleasure of processing basic EUDI wallet-authorized payments - which would be a major disincentive to use EUDIWs - or will this be limited to Payment Services Providers? A possible solution would be a blanket exemption of that requirement coming from the forthcoming Regulatory Technical Standards of the future Payment Services Regulation, but this arguably is not fully in line with the eIDAS registration requirement...Any views on this?

[alex-reit]

Well I always assumed that banks would have to register. But your line of argument gets me thininking that if a bank is obliged to accept EUDI Wallet for SCA then the register cannot deny a bank access to the ecosystem. Or a suspension for a bank would also not be possible.

And then we have to consider "certain use cases in the areas of transport, energy, social security, health, drinking water, postal services, digital infrastructure, education or telecommunications." (https://ec.europa.eu/commission/presscorner/detail/en/qanda_21_2664)

So these companies also don't have an option, they have to register and the register can't deny them access.

[sgmouy]

I think you are missing the point.
The payment use case is, like other use cases, voluntary for EUDI Wallet holders, but with the key difference that wallet users already have plenty of convenient alternatives - for example X-pay (wallet-based) solutions. So a very smooth UX and a very wide acceptance of EUDI wallet payments by merchants is required if adoption at scale of EUDI Wallet payments is to occur. Indeed, why would one bother to make an EUDI wallet payment if (i) only a few merchants/payees accept it and (ii) the same payment can be made in a frictionless manner with the same smartphone? Given that over 99% of merchants/payees are under no obligation to accept an EUDIW payment (Granted, the largest are, but they are a tiny minority), a wide acceptance network is key for the successful deployment of EUDI wallet payments - and this means reaching local SME merchants. But requiring them to register is very likely to be resisted - for good reasons as nobody has thought of imposing a similar requirement for other payment interactions. Frankly, this is regulatory overkill and likely to act as a major disincentive to accept EUDI wallet payments.
The bottom line is that the registration requirement is most unfortunate in 'non-voluntary acceptance' situations. It can only be hoped that a blanket sectorial exemption will apply for payment interactions as part of the Payment Services Regulation Regulatory Technical Standards.

[cre8]

I am not aware of any other situation where a party receiving personal data has to inform public authorities of its intended use of these before receiving those

For the last part you have the demand of the privacy policy by the GDPR. And the privacy policy needs to include information what data you are requesting BEFORE the user is sharing these data.
The biggest downside right now with the current state is that these information are spread out and it's difficult to validate it. Centralizing them gives better chances to detect violations and also gives an overview of the "demand" in the ecosystem.

[OBIvision]

I personally regret the registration requirement that uniquely applies to EUDI wallets (all other eIDAS eID schemes are exempted) and goes way beyond what GDPR imagined

I agree. This is exceptional bureaucratic - much worse than the dysfunctional cookie-popup.

En RP needs top be dynamic - preregistering or even having to publish what is exchanged is extreme and can only be based on an attempt to limit competition.

I would at least suggest to exempt in all use cases where the entire transaction remain unlinkable - whether accountable or not (a judge able to establish linkability would render all the data personal data even if the link is never established in which case e.g. the right to data portability and thus the RP becoming an Issuer apply).

[AlexEichler]

Dear all,

I think we all agree, that a Relying Parties need to register in at least one EU member state. Following Topics 1 to 3 to this.

Topic 1: Does a registration in one member state is enough to be registered in all member states?
Answer: it is sufficient that a Relying Party is registered in one country. Art. 5b section 1 eIDAS says: „shall register in the Member State where it is established“

Recital 5 and recital 10 of Draft „Commission Implementing Regulation … as regards the registration of wallet-relying parties…“ clearly result in one registration per relying party in one EU member state is sufficient for all member states. That registration takes place in the member state where that relying party is established (see above).

Argument 1: the requirements to register a Relying Party should be the same in all EU member states. Parallel to GDPR where it is assumed that the data protection standard is the same in all EU member states. Any requirement to register in all member states will be hindering the free market in EU, as Relying Parties will only register in their main market. But one of the main goals of EU is a free market through all member states.

Argument 2: Let‘s assume that a Relying Party must register in each member state it wants to offer its services. 
Question: with which information in the Wallet would that be matched to ensure that Relying Party is allowed to request information and/or trust services from a specific user? (a) the address information of that user stored in the Wallet (what to do if one Wallet contains multiple address information?) or (b) the GPS location of the device the User is using to interact with the Relying Party? Can we ensure that each of these devices can provide for a location information?

The more general question behind this is: which decision is been taken by register a Relying Party by an authority in a EU member state? Is such decision be valid for all EU member states or is it only valid for the member state of the authority?
If it is only valid for the member state state of the authority, the next question is: is the registration decision valid for the citizens of such EU member states or is it valid for the people being in the member sate at the time of the use of the Wallet?
If it is valid for the citizens, than we can use the address stored in the Wallet and it does not matter where the user is geographically located in the moment of the use of the Wallet.
If it is valid for the user being in the member state at the time of the use of the Wallet, we would need to include actual location data.

We get rid of all of this if we decided that a registration decision by one registration authority is valid for all EU member states.

Argument 3: Let‘s assume that a Relying Party must register in each member state it wants to offer its services. Further on assume that different registration authorities have provided for different registration decision, meaning, that in country A the Relying Party is allowed to ask for data set A while in country B it is data set B and so on. Yes, it is possible to cover this in an electronic system, but it complicates things a lot.

Consequence: the registration information provided by the registration office to the Relying Party and by the Relying Party to the user needs to include one or multiple countries to which that registration is valid. Is that part of the implementing act and applicable technical standard?
Now let‘s assume that one country disagrees from a data protection point of view and therefore want’s to de-register the Relying Party: technically easily done, as that specific country is deleted from the list of countries provided by Relying Party. 

Topic 2: A relying party has multiple subsidiaries in one or multiple countries. Is each of these single entities a relying party, which needs registration?

No decision by eIDAS or Implementing decision on this topic directly. But the wording in both documents always indicates that „a“ relying party is one (1) entity or natural person. Therefore each entity in need of the functionality provided by the wallet system needs to register as a relying party in its country of residence.

Topic 3: Is it possible that a natural person or legal entity not established in a EU member state (e.g. Switzerland, UK, …) registers as a relying party?

That‘s one of the pitfalls of eIDAS and the implementing decisions, they are limited indirectly by wording to the EU member states. On the other hand, EU has a high interest that this is possible, as this will bring these countries closer to the EU and that‘s a vital interest of all member states. Relying Parties are also users of wallets and business does not stop on boarders or is limited to EU member states. In many cases it is needed that entities outside EU can handle processes with authorities in EU seamlessly. We foster these electronic processes and strengthen our relationships with other countries if we open the wallet system to relying parties outside EU member states. 

In GDPR, a legal entity established in a third country has to instruct a representative an register via that representative. That‘s not needed in eIDAS. We have a secure method of document and therefore information transfer as one of the trust services listed in eIDAS. The potential relying party may select any registrar in any EU member state and register. To open it to „any registrar“ brings a competitive aspect to the registrars - which is, as we know, a positive thing to do.

We would need to adopt the wording of eIDAS and the implementing decisions accordingly. But that‘s easily done.

[alex-reit]

Dear all,

I think we all agree, that a Relying Parties need to register in at least one EU member state. Following Topics 1 to 3 to this.

Agreed.

[...]

Topic 1:
[...]
Consequence: the registration information provided by the registration office to the Relying Party and by the Relying Party to the user needs to include one or multiple countries to which that registration is valid. Is that part of the implementing act and applicable technical standard? Now let‘s assume that one country disagrees from a data protection point of view and therefore want’s to de-register the Relying Party: technically easily done, as that specific country is deleted from the list of countries provided by Relying Party. 

I like your line of thinking. I think it comlicates things and probalby would hinder adoption and cross-border use cases, so a lot of negative aspects, but as long as we don't have common legislature in the EU, we should at least point it out and consider the possibility that de-register from a certain country is possible without affecting other countries registerting.

[alex-reit]

In GDPR, a legal entity established in a third country has to instruct a representative an register via that representative. That‘s not needed in eIDAS. We have a secure method of document and therefore information transfer as one of the trust services listed in eIDAS. The potential relying party may select any registrar in any EU member state and register. To open it to „any registrar“ brings a competitive aspect to the registrars - which is, as we know, a positive thing to do.

We would need to adopt the wording of eIDAS and the implementing decisions accordingly. But that‘s easily done.

Hm, your line of argument so far was, that a company has to register in it's country of origin. If you are a subsidiary then you can't rely on your mother company but have to register yourself. Okay so far.

But now you open up that a non-EU company might register anywhere. Don't get me wrong, I agree with you so far, but do we have a situation where non-EU companies have an advantage? Let's say I'm a company from A and want to offer a specific service in B. I would have to register in A and also being accpeted by the B registrar, wheras a non-EU company can choose where to register himself and just do the registration for his B services in B? I'm not sure here, just thinking - what do you think?

[AlexEichler]

„I like your line of thinking. I think it comlicates things and probalby would hinder adoption and cross-border use cases, so a lot of negative aspects, but as long as we don't have common legislature in the EU, we should at least point it out and consider the possibility that de-register from a certain country is possible without affecting other countries registerting.„

That‘s interesting. As stated, we only have one (1) registration valid in one (1) EU member state be valid for all EU member states in the EU documents. But we need to discuss that this leads to one (1) de-registration possibility or to de-registration state by state as long as the „root“ registration is not de-registered. First impression: one registration equals one de-registration.
Argument: if we have a de-registration state by state, we have a situation like registering state by state.
Consequence 1: We would need to adapt the technical standards and the Annex to the draft implementing decision for relying party registration to allow to have a list with all EU member states countries embedded and processed in case of a request to a user using a wallet.
Consequence 2: We would need to decide if the place of residence or the actual place where the use is in the moment of the request is, is basis to decide if the request is legally valid or not. If the later, we would need to locate the user and would need consent under GDPR to do so, as there is no legal ground to process such data otherwise. That would be critical for many users and users might be outside EU. Therefore solution one: place of residence should be relevant. Consequential can only accept identification methods including place of residence. That‘s an issue! In many cases users will use documents that do not include a place of residence to identify. And I am not sure that all states have official documents stating the place of residence. That leads to a result: A request by a relying party to a user using a wallet, can‘t be depending on where that user is situated (residence, actual place) and therefore we do not have a list of all EU member states in the relying party certificate and we do not have de-registration state by state.
Happy to discuss if you have any better ideas!

[AlexEichler]

„ But now you open up that a non-EU company might register anywhere. Don't get me wrong, I agree with you so far, but do we have a situation where non-EU companies have an advantage? Let's say I'm a company from A and want to offer a specific service in B. I would have to register in A and also being accpeted by the B registrar, wheras a non-EU company can choose where to register himself and just do the registration for his B services in B? I'm not sure here, just thinking - what do you think?“

Yes, that‘s forum shopping and we will not have an argument to do this in any other way, if we allow non-EU relying parties to participate on EU wallet. We need to see that there are multiple big areas where the wallet will be used: B2C and B2B and B2authorities and C2authorities.
For non-EU relying parties the B2authorities aspect is of high importance. Just think from EU perspective: one of the goals to implement a wallet system is to be able to move all bureaucracy to digital age and lower costs… now, EU is heftily woven into the international trade and many relying parties from outside EU have business with either entities in EU or with people in EU. That means that most of these relying parties from outside EU have a lot of communication with authorities in EU. Would we like to have separate business processes at all these authorities for relying parties with residence and outside EU? That will kill any financial benefit we gain with wallets in regard to authorities as relying parties.

We could argue that the non-EU relying party has to register in a state it is targeting in its offering. If it offers its services in multiple EU member states, it is forum shopping in these member states. So no registration in Denmark if your offering is in Italy and Spain. But register either in Italy or Spain and have a free pass to other EU member states if you like to geographically broaden your offering.

Consequence: we need to open up the wording in eIDAS and in the draft implementing decision on how to register a relying party to allow for potential non-EU member state relying parties to register in a EU member state.
Alternatively we allow for registrars outside EU member states - which is another highly interesting topic, as we could spread the European wallet system to other countries and regions. Think of either: if the EU has implemented an adequacy decision under GDPR like fro UK, Switzerland, Canada, … not like for USA, EU would accept registrar certification applications from such countries if all other aspects are fulfilled. Or if EU has a free trade agreement in place (as EU has with many countries, see here) EU would accept registrar certification applications.
What do you think?

[samuelmr]

Some people have interpreted the legislation so that if an airport has a row of passenger terminals reading information from an EUDI Wallet or a shop with a row of cash registers, all these systems or devices are separate Relying Parties and need separate certificates.

Can someone

• either confirm that the interpretation above is correct
• or clarify that this is not the case, the certificates are issued to organizations, and different access points can share the same certificate?

[cre8]

@samuelmr from my interpretation all the systems belong to the same relying party called "nice shop", but each system is able to have a dedicated access certificate as x509 to allow a dedicate private key for each system. So in case one system is compromised, you can revoke this system without shutting down the rest.

So a relying party is able to have and use multiple access certificates.

[stefan2904]

Then your e.g. 100 terminals will all use the same RP registration certificate to get their 100 access certficates and then can process data exchanges with travellers wallets

Are you sure?

Isn't there one RP-Access Cert (RPAC) per RP Instance, and one RP-Registration Cert (RPRC) per RP per use case?
So, in your case, the airport IT company is the RP; each scanner is an RP Instance with its own RPAC, but all scanners share the same RPRC.

And RPACs are X.509 certs, while RPRC are either X.509 authorization certs (RFC 5755) or something else?

(I am asking because I am also a bit confused about that part.)

[alex-reit]

No, not sure, but happy to discuss.

So...

1 relying party registration certificate (holder is the airport IT company)

100 Relying Party Instance Access Certificate (holders are the terminals)

to quote a sentence of mine "I believe that the terminals are RP instances and they will not be indiviual RP"

I think we agree, do we not?

[stefan2904]

I think we are on the same page for that concrete example, where there is only one use case (so only one registration certificate). :-) Thanks for the clarification.

It gets a bit more confusing for scenarios where one RP has multiple RP instances (= access certificates) and use cases (= registration certificates).

---

The second point is from whom they get those certificates:

you will see that the RP instance will receive the RP registration certificate from the RP
...
They will get their RP registration certificate from your RP (e.g. the airport IT company who registered as RP with your RP registrar).

In the linked ARF it says

a Relying Party Instance Access Certificate Authority (CA) associated with the Registrar issues an access certificate to each Relying Party Instance of the Relying Party

In my understanding, the RP CA issues the cert directly to the RP Instance.
The RP is not an intermediate CA that then issues access certs to their instances.

[alex-reit]

That was sloppy writing on my part. I was thinking about the point of terminals being RP instances. I wasn't thinking about where the RP access certificate comes from.

In my understanding, the RP CA issues the cert directly to the RP Instance. The RP is not an intermediate CA that then issues access certs to their instances.

Agreed!

[OBIvision]

Excessive bureaucratic and market damaging registration - "Topic X - Relying Party Registration"

In the aspects of Relaying Party, there is an indication that the ARF MIGHT require Relaying Parties to register what data/credentials they want to request.

Such a requirement would be excessive bureaucratic as data requests are likely to be highly dynamic and in some cases also sensitive. E,g. EDHS will require a vast set af data that can potentially be requested subject to constant change and additions.

Such a requirement would be invented by the ARF group without ground in legal requirement and as such in itself constitute illegitimate surveillance.

[OBIvision]

Guys, politely. Take a step back here and stop being so naive.

Please criticize ideas, not people

Sure. Not criticizing people, but the thread as such.

Just pointing out that unlinkability is a much more complex issues that seems to be addressed with means that are literally counterproductive. We see a lot of that in EU - and it needs to stop because it is basically given the market to BigTech and leaving bureaucrats insensitive to the serious problems.

[samuelmr]

For the part "the user can see which relying party can access it". Does not work for our approach, we are suggesting that the EAA provider defines a presentation request like "only RPs that have the following credentials are authorized to request this diploma", because you do not want to manage a list of thousands of RPs.

I didn't mean that the relying parties would be listed in the credential's embedded disclosure policy.

If the credential says "only to be presented to relying parties with a wallet-relying party access certificate from Registrar X", the user could see the list of intended relying parties from Registrar X's service or from a service using Registrar X's API.

[samuelmr]

@samuelmr ad 1: I think you find your first answer in ARF ch 6.6.3.4 "The Wallet Unit presents the outcome of the disclosure policy evaluation to the User in the form of advice, when requesting User approval. For example, "The issuer of your medical data does not want you to present to . Do you want to continue?" Note that the User can overrule the disclosure policy evaluation outcome." since the user can override in this example, I would say he can also override in your question (no-policy). Or in other words, the wallet does not limit, it only informs.

That doesn't mean that there is legislation forcing all relying parties to acquire registration certificates. ARF is not legislation. My point in the comment 12623629 was that your reasoning in the comment 12598601 wasn't sound.

My question was not related to whether the wallet limits or informs. My question was: Is there an embedded disclosure policy if the disclosure policy value is "no-policy?" If not, eIDAS Article 5a(5)(e) doesn't apply to all cases.

ad 2: I don't see the problem here. Has the permission to ask is passive, the RP can ask but does not and once the holder wants to interact with some use case of the RP the permission becomes "active" and the RP will ask for said data. Maybe not all of what they registered for, depending on their use case. Maybe you elaborate the difference more? Sorry, I don't see it currently as big thing.

IMHO, "has the permission" implies that someone has granted the permission. Who has given the relying party this permission and based on what?

If Ali's Döner kiosk has acquired a registration certificate saying that they will ask for your age, credit card number, and all your medical records, can they claim to have the permission of some authority to your medical data?

[cre8]

That doesn't mean that there is legislation forcing all relying parties to acquire registration certificates

The current 5b says that Member States MAY offer to issue registration certificates. It also says that when a Relying Party is overasking, the user should be warned.
Which comes with the dilemma when one company from a Member State wants to register the intended use, but there is no offerd service in this Member State, it will result in warnings when interacting with other EUDI Wallets.

To avoid the, the Registrar should be a MUST, so all Relying Parties in Europe have a chance to register their intended uses and pass them to the Wallets without leaking information about the interaction (Wallet to RP) to the registrar.

When the policy is set to "no-policy", all Relying Parties with a valid access certificate can receive the credential without a warning. When there is a policy (like allow list or root of trust) and the RP is not authorized, there should be a warning (that can be overruled by the user).

I have found no information how the Wallet should behave when the RP's access certificate is not valid, if this also results in a warning or in this case the Wallet will abort the connection.

[OBIvision]

So there is a legal ground in eIDAS to describe this topic in ARF.

Do we agree? Or do you read the above mentioned section differently?

It is in my view both with present legal text and as more principles view excessive to require thirdparty to register or collect information about society processes.

That the wallet client-side inform the user of data requests and there is some mechanism to monitor if you cross the somewhat fluffy boundary between unlinkable and linkable is fine and truly justified.

We know that most service provider will try to ask too much information in order to linkable identify the citizens (Who said Google cookies discussion).

What is NOT justified is that this
a) Happens serverside (as it is nobodys business)
b) involve some kind of mandatory pre-registration or dictate

Because that would mean a bureaucratic interference in the market involving both illegal surveillance in itself and severe restrictions on market competition. A lot of processes will be dynamic with multiple requests and with many stakeholders that may or may not have access.

[ad-Orange]

On the management of RP rights to access attributes
We understand and share the overall concern. We also think that the proposed way of doing things has merit and is not so far from a good compromise. We would however advise to use a slightly different scheme:

• The RP would notarize each of the request type they want to be able to make in an immutable ledger. This notarization does not need the approval of anyone (except to avoid flooding / DDoS but not any sort of approval related to the content of the request)
• Whenever they want to make a request to a wallet, they have to reference one of these notarized requests (this can also be made offline)
• Some log is kept on the wallet side of each request
• If, later on, some legal dispute arises about the legitimacy of some request, the issuer will not be able to plead innocence without justifying the legitimacy of the immutably stored request

The idea is that malicious RPs could cheat once, but they wouldn’t have any interest for doing so because they’d be sure to be caught and pay the price. On the other hand, the vast majority of RPs who do not have the slightest intention of being malicious would face little friction and could operate swiftly with just machine registration of their request without any sort of validation from anyone.
We think that defining a way to formally describe request that need to go through a very well defined reduced set of interoperability specification would be much easier than defining a policy definition language (as discussed in topic D) and would be sufficient for the goal to be achieved. This would replace (but is actually just an evolution of) the current proposal of registering the attributes to be asked.
Even though we don’t think that such request representation format would not be extremely difficult to draft, in the meantime, the current compromise of registering the attributes to be asked could be acceptable.

On the types of registration
We think that it makes sense to have 2 types of certificates as you’re proposing but they would be linked to 2 types of registrations. The first registration (corresponding to the RPAC) would correspond to the registration of the entity whereby the second one (corresponding to RPRC) would be linked to notarizing request in the immutable ledger (see above). This is once again here no revolution as compared to what is currently proposed but we think it would be useful to be clearer on the detailed semantics.

On intermediaries
The very notion of intermediaries arguably theoretically goes against the SSI approach that was followed (and rightly so, we think) by the ARF. We have not seen anywhere in the ARF where this notion is addressed heuristically and comprehensively to get a better grasp on the necessity for it and the drawbacks it introduces so that they can be compared rationally and systematically. We think it should be the object of an upcoming topic to ensure all the aspects of it are properly taken into account.

[OBIvision]

All VCs are linked to the same WSCD and wallet (and thus it’s clear that they’re coming from the same individual)

Politely - and then lets stop the discussion of BBS# here and I just emphasize that I am not criticizing the work on BBS# which appear rather good.

How do you unlikable link unlinkable VC to the same WSCD?
Issuers (which were RPs) do not share identifiers and a shared key would become an linkable identifier in itself.

Fact is - unresolved, but abusing the underlying lack of security in non-pseudonym PID used to issue linkable VC which require every Issuer to do active linkable surveillance which is of course unacceptable and a technical security flaw in ARF.

In short, BBS# is not the magical dust that solves the unlinkability requirement.

[ad-Orange]

The shared key is the private key of the holder (which it is the only one to know). It is indirectly embedded in all VCs but in a way that is not recognizable and unlinkable by the outside world (it uses a cryptographic feature called “commitments”; they need to be of the right kind to achieve everlasting privacy) except whenever the holder decides to make a ZKP to prove it. That’s the magic of ZKP and how you unlikable link unlinkable VC to the same WSCD.

[OBIvision]

The shared key is the private key of the holder (which it is the only one to know). It is indirectly embedded in all VCs

Sure, Petersen Commits have been known from e.g. U-Prove for more than 20 years.

But it is not that simple - for many reasons.
First problem - what happens when you lose your phone and need to revoke keys without revoking all history ?

[ad-Orange]

That’s another problem that I will not tackle here. You raised an issue, I answered it. You can change the topic if you want but it doesn’t change the fact that your concern was answered.
The question you’re asking will be addressed but requires much more than a short chat.

[OBIvision]

That’s another problem that I will not tackle here. You raised an issue, I answered it.

Agree to disagree. A universal hidden key has lots of problems.

[AEPDmbeltran]

On behalf of the Spanish Data Protection Authority (AEPD)

The attached document contains our comments on this topic.

topicX AEPD response.pdf

Thank you very much for this opportunity to contribute to this important discussion.

[stefan2904]

Thanks!

Crucially, RPs are explicitly prohibited from requesting any data beyond what is indicated in their registration.
This is a key mechanism for enforcing data minimisation and purpose limitation.

Is this an argument for RP registration certificates being mandatory?
Or is the publication of the indicated data used in the MS register enough?

Is this an argument for the indicated data use (list of attributes) being enforced by the wallet instead of merely displayed to the user?

[cre8]

Thanks!

Crucially, RPs are explicitly prohibited from requesting any data beyond what is indicated in their registration.
This is a key mechanism for enforcing data minimisation and purpose limitation.

Is this an argument for RP registration certificates being mandatory? Or is the publication of the indicated data used in the MS register enough?

Is this an argument for the indicated data use (list of attributes) being enforced by the wallet instead of merely displayed to the user?

For privacy reasons the RP needs to pass the registration certificate that includes the intended use to the Wallet. Otherwise the Registrar would know which wallet is interacting with which relying party when the Wallet fetches it from the registrar.

[phin10]

@AEPDmbeltran, thank you for your input to the discussion on topic X. Please find below the response of the @eu-digital-identity-wallet/arf-writers:

Thank you for your letter received on Topic X discussion paper, it has been duly analysed and taken into account in the ARF version 1.10 and the High Level Requirements definition in the ARF Annex 2.

Since receiving the letter with its listed concerns, a few updates have taken place regarding relying party registration. The final version of the CIR for Relying Party Registration (CIR (EU) 2025/848) has been published, and the Comitology meeting of April 2025 has decided that the Relying Party Registration Certificates are only optional, thus it is going to be up to Member States whether those will be issued for Wallet-Relying Parties registered in the national Relying Party Registrar. An update to the ARF (version 1.10, a candidate release for ARF 2.0) has been released and the Topic X related parts have been updated to match with the up-to-date situation.

First, the goal of the ARF and HLRs is to address the technical requirements resulting from the eIDAS regulation, while not aiming to address or clarify all possible legal or conformance concerns resulting from other regulations, like General Data Protection Regulation (GDPR). At the same time, the GDPR requirements are still to be applied properly by the Wallet Relying Parties and other actors, whenever applicable, in addition to the technical requirements set out by the ARF.

Herewith your input and our response:

AEPD: The Relying Party (RP) registration requires RPs to provide information necessary for authentication, their contact details, and the intended use of the European Digital Identity Wallets, including the specific data they will request from users. The RPAC (wallet Relying Party Access Certificate) authenticates who the Relying Party is, while the RPRC (wallet Relying Party Registration Certificate) specifies what data that authenticated RP is entitled to request for a particular registered purpose. Both certificates are crucial for establishing trust and ensuring transparency and user control within the European Digital Identity Wallet framework, contributing to data protection by limiting data requests to registered intended uses. Crucially, RPs are explicitly prohibited from requesting any data beyond what is indicated in their registration. This is a key mechanism for enforcing data minimisation and purpose limitation.

For this to be entirely true, it is required further clarification within the ARF on:

• Registration updates and lifecycle (new data, new use cases, certificates revocation)
• Multi-registration (per use case, per MS) and cross-border registration.
• Post-registration analysis and audit (is the RP complying with its registration?) and Data Protection Authorities role.

Response: First, after recent changes the RPRC may no longer be relied upon as the universal tool for ensuring the expectation of full transparency is met, as they will be optional and thus there will be alternation between Member States regarding their issuance to the RPs. The ARF main document and Annex 2 have been revised and reworked to adapt the concept to situation where there is no RPRC and meet the same goals. The updated concept envisions alternative method for Wallet Units to access RP registration information - an on-line service provided by a Registrar. It includes placing specific information in RPACs and/or in presentation requests to point out that a RPRC is not available and how to access the Registrar's on-line service (URL). In result, the situations presented in the questions will not take place.

This does not diminish the need to emphasise the need to provide technical tools (such as common APIs) for the RPs to provide updates for their intended use-specific registrations. See part of our latter response related to lifecycle management of the intended uses at the Registrar.

Upon revocation or suspension of an RPAC, the corresponding RPRCs of the RP in question (or the intermediary RP, if such is subject of the earlier) shall be revoked by the respective RPAC issuer. Provided that RPRCs are not issued, there needs to be an online mechanism available to validate the registration information from the Registrar dynamically before accepting a presentation request by the Wallet Unit. The Registrar API - being defined as new TS5 by the European Commission - caters for this, though with some privacy caveats related to Registrar eventually gaining information about the User of the Wallet Unit.

Our understanding of the multi-registration and risks related to it; the CIR is enforcing the RP registration to be executed only in the Registrar of the registration country of the entity.

AEPD: We have two additional concerns regarding GDPR compliance:

1. RP contact details that must be registered to ensure the exercise of data subject rights.
2. Compliance of principles such as lawfulness, fairness, transparency, storage limitation or accountability and of requirements such as those related to data subject rights when using an Intermediary RP. This new role introduces privacy threats that must be carefully analysed and mitigated, among other measures, with this registration process. This concern is transversal to several ARF discussion topics, given that this new role raises many doubts/unknowns that we would like to see resolved as soon as possible.

Response: As a general starter of our response, here is an equivalent statement that we are providing in our response to your questions on Topic N: The ARF defines only High-level Requirements, and the detailed requirements of data protection compliance can be found from the applicable certification and auditing processes, particularly the ones referenced in the CIRs. The European Commission is developing common specifications, defining the general and role-specific security policies to be applied in evaluation of Wallet-Relying Parties upon their registration to the respective national Registrar and issuance of Relying Party Access Certificates. The actual onboarding process, with requires audits for Relying Parties registering to a Registrar, it is for the Member States to design, implement and publish.

For concern 1 on RP contact details, it can be noted that:

• the final CIR text and the upcoming EC technical specifications on data to be registered do require that the Wallet-Relying Party registers at least a web address, email address or phone number for addressing the help desk functions the Wallet User might need, and the applicable DPA address of the registering Wallet-Relying Party.
• For exercising the data subject rights, there is also mandatory requirement to register the privacy policy URI for each intended use of the Wallet-Relying Party. A GDPR-compliant privacy policy shall include a redress/contact address for the data subject to use when needed.

For concern 2 on compliance over the data protection principles with intermediaries, the ARF, CIR and upcoming technical specifications provide the following tools and requirements:

• The CIR (EU) 2025/848 requires the DPA and privacy policy information also from registering intermediaries, to allow contacting the entity and as the formal validation basis for the data processing taking place as part of the intermediating function.
• The end-Relying Parties shall provide their respective privacy policies (policy URIs) upon registration, so that this information can always be propagated to the Wallet User.
• The intended use registration attributes include a ‘created at’ and ‘revoked at’ dates for improving the traceability of intended use lifecycle changes at the Registrar.
• The description of the expected technical process when ‘end’ Relying Parties are depending on an intermediary has been updated in the ARF – see Section 3.11 in ARF version 1.10.
• Section 3.11 item 7 on the duty of the intermediary to delete all processed personal data related to an on-behalf-of transaction after sending it to the ‘end’ Relying Party.

These are technical level tool provided to improve the chances of the Registrars and other bodies supervising the different Wallet-Relying Parties to build their own onboarding and monitoring processes, that are necessary to avoid the problems your concern raises.

[DC4EU-Consortium]

On behalf of DC4EU LSP:

Following the latest additions in this topic (Version 0.3), the proposed RP registration and Attribute Authority (AA) frameworks appear to address most of the initial concerns and provide a solid foundation. However, the suggested mechanism—based on Public Key Certificates (PKCs) and Attribute Certificates (ACs)—while functional, risks creating a "European island" in terms of interoperability. This should be considered in future iterations.

To ensure long-term scalability, the EUDI Wallet ecosystem would benefit from more agile and dynamic mechanisms for governing policies and permissions. One possible direction would be to extend the current schema to support (pluggable) delegated access policy decision mechanisms. Such mechanisms could enable API-based policy evaluations and reduce reliance on revocation-heavy models, considering that certificate revocation has long been a known point of friction when traditional X.509-based approaches are involved.

Classification of mandatory and optional attributes
In most cases, the attributes that a Relying Party (RP) is eligible to request from wallet holders are determined by the declared purpose or legal justification for their use (intended use). To align with data protection principles and ensure effective attribute-based access control, these attributes should be classified based on their relevance to specific service contexts.
A key distinction should be made between mandatory and optional attributes within each group. Mandatory attributes are essential for the provision of the service, while optional ones may enhance the service but are not strictly required. This classification helps minimize data disclosure leveraging selective disclosure, supports purpose limitation, and enables users to make informed decisions.
Importantly, it also prevents the practice of presenting long, undifferentiated lists of requested attributes—where critical, legally justified attributes are mixed with optional or "nice-to-have" ones. By enforcing this separation, Relying Parties are discouraged from making excessive or opaque requests, and the truly necessary data becomes clearly identifiable and justifiable.
To enforce this model consistently, the WRPRC (registration certificate) should explicitly define these attribute groupings, clearly distinguishing between mandatory and optional attributes. These groupings must be tied to the RP’s declared purpose and established at the time of RP registration.

[stefan2904]

To enforce this model consistently, the WRPRC (registration certificate) should explicitly define these attribute groupings, clearly distinguishing between mandatory and optional attributes. These groupings must be tied to the RP’s declared purpose and established at the time of RP registration.

I think there are even three categories of attributes:

• mandatory for legal reasons, e.g., KYC
• "mandatory" for functional reasons
• optional

---

The Implementing Act on RP Registration (draft from the Consultation) also talks about this in its Appendix I ("Information regarding wallet-relying parties")

and in the Appendix V ("Requirements for wallet-relying party registration certificates")

[cre8]

You always need a legal reason to ask for the data: GDPR is the legal basis for this. If you do not have any good reason to ask for it like "I need your age to show you over 18 content" or "I need your address to deliver your order".

The only difference according to eIDAS is: when you have a law that is demanding identification, you can just ask for the PID. In all other situations, you need to give the chance to use a pseudonym, aka self attested data like entering them in a normal form.

The challenge from the Registrar is to validate if the RP really has a law that allows it to request it. If it's validated before, you have prevention. But because of the KYC process you can even legally charge them after the issuance

[OBIvision]

The only difference according to eIDAS is: when you have a law that is demanding identification, you can just ask for the PID. In all other situations, you need to give the chance to use a pseudonym, aka self attested data like entering them in a normal form.

This is one of the main problems with the ARF as-is because it gets abused to make a lot of illegal surveillance instead of security.

"when you have a law that is demanding identification" does not imply "you can just ask for the PID".
It is still subject to interpretation according the data minimization and necessity according to best technical alternative. In almost all situations what is legally required is not linkable identification but some assurance e.g. "This Person is not Wanted by the Police" or accountability as in "A judge can establish a link between the pseudonym and the linkable identity represented by PID"

Problem is that the lawmaking process is not precise, i.e. terms do no mean the same in different context.

From a legal, security or economic point of view - a pseudonym with some sort of accountability is ALWAYS better than linkable identification as linkable identification always have some kind of negative side-effect and creating personal data often without necessity.

It also have drastic impact on this discussion - with a pseudonym much more data can be collected in a context without violating the unlinkability objective. Without a pseudonym any data created violate the data minimization criteria if not necessary if a pseudonym was used.

[stefan2904]

RP Registrar vs. RP Certificate Provider

The latest commit to the Topic X Discussion paper mentions the following:

a443b29#diff-3f189aab29624916233ee998e80b6bca6b5ff404e49b0e72065566001e94b971R757

The ARF does not contain the concept of a Trusted List of Relying Party Registrars. Yet, Topic 44 says that such Registrars sign RP registration certificates, and that Wallet Units must verify the authenticity of these certificates.

According to the implementing act, access and registration certificates are issued by "provider of wallet-relying party access/registration certificates", not by "registrar of wallet-relying parties". Did the ARF merge those entities?

[AltmannPeter]

Topic X needs to be updated to align with the published CIR: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202500848&qid=1746798216872

The Topic X text mentions claims and requirements that are both problematic and unsuitable, and does not align with the current CIR version linked above. The CIR is practically feasible; the present Topic X text is not.

[Nathall7]

Within the TS 6 Common Set of Relying Party Information to be Registered (lastest version 23rd of May), there is no request of the URL adress of the webpage of the service accessible by users (that contain the link to their privacy police and terms of use). The TS is only referring to one uniform resource identifier (‘URI’) belonging to the Wallet-Relying Party with web page(s) for information about the entity, if applicable. I highly suggest that any relying party accessible by web shall be identified by the webpage address related to this service accessible by wallet holders, with a must have request for the provision of the related validated QWACS, that will certify both the domain of the web page and the identity attributes with the related reference of the unique identifier, so that the registry can verify the web adress is related to the same RP identity. Indeed, even if the wallet is delivered with an mobile APP, cross device flows with web pages will occurr and to prevent phishing the relying party access shall be verified also (without the absolute need of the device credential API). QWACS is a also a must have for mutual authentication.

[burdges]

If I understand, "Relying Party" means "party who is allowed to request information from user's identity wallets."

We need some framework like this:

User's wallets must always first validate that the "access certificate" sent by the relaying party authorizes whatever request the relaying party made.*

These relaying party access certificates must only be issued by auditors who actually look at the technical and organizational processes being used to handle whatever PII the relaying party requests. A self assessment by the relaying party should never suffice, unlike other domains of EU law.

These auditors need an auditor certificate which traces back to the data protection authority (DPA) of the nation that issued the credential being used by the user. It's typical that EU nations trust one another's processes, which works fine for the user's wallets themselves, but does not work for the auditors, since some nations like Ireland or Hungary would rubber stamp every auditor or relaying party.

An auditor cannot know which nation issued the user's credential when supplying its certificate, so instead the auditor provides a few certificates that originate in several national DPAs, and users' wallet should update an internal list where different national DPAs certify other national DPAs.

In practice, this all means national DPAs that rubber stamp auditors should be decertified by other national DPAs. If say Germany has a strict DPA, then German credentials should fail completely for relaying parties who do not get audited by some auditor who themselves was audited by a DPA the German DPA likes.

We need a process like this to prevent a race to the bottom, in which the most irresponsible DPAs become dominante, and then users risk doxing, identity theft, etc when using their wallet.

There are only 200 nations in the world, which is 40k possible certificate edges between national DPAs, but a user's wallets need only store its own neighborhood in this graph.

• We could discuss one niche exception where the wallet proves only a "ring VRF" output whose input includes something like the TLS public key of the domain in the browser address bar, but this requires discussion.

[jschanck]

@david-bakker writes

There are two separate issues here. One is the fact that registration certificates are optional. This was a political compromise, and personally I agree that from a technical point of view this is really unfortunate.

The other issue is whether it's a good idea to encode registered data in the access certificate, instead of having separate registration certificates. On that one, for me it's quite clear that we shouldn't do that, because it means that you are doing authentication and authorization in the same certificate. In any good access system, these two are decoupled, because it must be possible to change somebody's authorization without changing their authentication (method).

Making registration certificates optional made it impossible to design a "good access system" in your sense. The question is how to obtain a satisfactory access system given the political compromise that was made.

Encoding a list of requestable attributes in each access certificate is the best option.

An alternative is to have an extension in the access certificate that indicates that a registration certificate exists and that it MUST be presented with all requests. This would let wallets automatically reject improper requests from RPs that have registration certificates. However, it would still leave users vulnerable to RPs that do not have registration certificates, so it is not satisfactory.

But access certificates are X.509 certificates containing a public key; issuing a new one is not entirely trivial (despite being possible, of course). [...] If purposes were encoded in access certificates, this means multiple access certificates and hence more key management. Again, having multiple registration certificates is easier because they don't involve cryptographic keys.

Other PKIs have solved both of these problems before, and there are off-the-shelf solutions available.

[david-bakker]

@david-bakker writes

Making registration certificates optional made it impossible to design a "good access system" in your sense. The question is how to obtain a satisfactory access system given the political compromise that was made.

Encoding a list of requestable attributes in each access certificate is the best option.

Essentially, what you are proposing here is to circumvent the political choice that registration certificates are optional by moving the contents of the registration certificates to mandatory access certificates. But doing so would obviously not be acceptable to those Member States that decided they don't want to issue registration certificates. (Plus, of course, this would mean that registration certificates are not needed anyway, contradicting some of the Implementing Acts.)

An alternative is to have an extension in the access certificate that indicates that a registration certificate exists and that it MUST be presented with all requests. This would let wallets automatically reject improper requests from RPs that have registration certificates. However, it would still leave users vulnerable to RPs that do not have registration certificates, so it is not satisfactory.

We have thought about that, but at least up to now to my knowledge this has not made it into the definition of the access certificates. Anyway, as you say, it's only a partial solution.

Indeed the question is how to obtain a satisfactory access system given the political compromise that was made. The ARF requires that if there is no registration certificate, an RP must share the data (Registrar service URI, RP identifier, RP purpose identifier) that allows the Wallet Unit to go online and check the registered data for this Relying Party directly at the Registrar's online service. That ensures that the Wallet Unit can always check the registered data, either locally by inspecting the registration certificate, or online. However, obviously going online is bad for User privacy, since the Registrar then gets to know the RPs that the User is interacting with, plus the times of those interactions, plus the purposes of interacting. Therefore, the ARF leaves it to the User to choose if they want to do that. I think it's the best we can do given political realities.

[cre8]

Encoding a list of requestable attributes in each access certificate is the best option.

Implementing acts are forcing that intended use is in the registration certificate, not the access certificate: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202500848

Making registration certificates optional made it impossible to design a "good access system" in your sense. The question is how to obtain a satisfactory access system given the political compromise that was made.

Registration certificates are a signed export of the registrar. So even when a member state is not supporting it, the wallet can fetch the data via the API.

Other PKIs have solved both of these problems before, and there are off-the-shelf solutions available.

It's not just about encoding roles/entitlement, but using a query language giving much more flexibility. This is a nightmare with x509 encoding, but quite easy with JWTs since it is encoded as JSON like DCQL that is used for OID4VP.

[jschanck]

@david-bakker

Essentially, what you are proposing here is to circumvent the political choice that registration certificates are optional by moving the contents of the registration certificates to mandatory access certificates. [...] (Plus, of course, this would mean that registration certificates are not needed anyway, contradicting some of the Implementing Acts.)

No, that's not what I'm proposing. Registration certificates carry important data, such as the URL of a privacy policy (article 8 clause 3 of 2025/848), that I am not suggesting we put in the access certificate.

I am not suggesting we get rid of registration certificates. I am only suggesting that an allowlist of attributes be encoded in the access certificate.

But doing so would obviously not be acceptable to those Member States that decided they don't want to issue registration certificates.

This is not obvious to me. One could imagine that there are Member States who are opposed to registration certificates for reasons that are compatible with my suggestion here. Perhaps you can cite some statements by representatives of Member States to convince me otherwise.

@cre8

It's not just about encoding roles/entitlement, but using a query language giving much more flexibility. This is a nightmare with x509 encoding, but quite easy with JWTs since it is encoded as JSON like DCQL that is used for OID4VP.

This is not true. All that is needed is a list of attributes. And even if JSON were required for some reason, the technical standards are free to define an X.509 extension that carries JSON encoded data.

[cre8]

@david-bakker

Essentially, what you are proposing here is to circumvent the political choice that registration certificates are optional by moving the contents of the registration certificates to mandatory access certificates. [...] (Plus, of course, this would mean that registration certificates are not needed anyway, contradicting some of the Implementing Acts.)

No, that's not what I'm proposing. Registration certificates carry important data, such as the URL of a privacy policy (article 8 clause 3 of 2025/848), that I am not suggesting we put in the access certificate.

I am not suggesting we get rid of registration certificates. I am only suggesting that an allowlist of attributes be encoded in the access certificate.

But doing so would obviously not be acceptable to those Member States that decided they don't want to issue registration certificates.

This is not obvious to me. One could imagine that there are Member States who are opposed to registration certificates for reasons that are compatible with my suggestion here. Perhaps you can cite some statements by representatives of Member States to convince me otherwise.

@cre8

It's not just about encoding roles/entitlement, but using a query language giving much more flexibility. This is a nightmare with x509 encoding, but quite easy with JWTs since it is encoded as JSON like DCQL that is used for OID4VP.

This is not true. All that is needed is a list of attributes. And even if JSON were required for some reason, the technical standards are free to define an X.509 extension that carries JSON encoded data.

We can skip this part because of two reasons:

• the implementing act defines which data should be included in which certificate and the ARF has to follow it (I linked the 5b above)
• ETSI published the standard that defines the technical schemas that all have to follow, see https://www.etsi.org/deliver/etsi_ts/119400_119499/119475/01.01.01_60/ts_119475v010101p.pdf

[AlexEichler]

Dear all, I think we all agree, that a Relying Parties need to register in at least one EU member state. Topic 1: Does a registration in one member state is enough to be registered in all member states? Answer: to my understanding it is sufficient that a Relying Party is registered in one country. Art. 5b section 1 eIDAS says: „shall register in the Member State where it is established“ Argument 1: the requirements to register a Relying Party should be the same in all EU member states. Parallel to GDPR where it is assumed that the data protection standard is the same in all EU member states. Any requirement to register in all member states will be hindering the free market in EU, as Relying Parties will only register in their main market. But one of the main goals of EU is a free market through all member states. Argument 2: Let‘s assume that a Relying Party must register in each member state it wants to offer its services. Question: with which information in the Wallet would that be matched to ensure that Relying Party is allowed to request information and/or trust services from a specific user? (a) the address information of that user stored in the Wallet (what to do if one Wallet contains multiple address information?) or (b) the GPS location of the device the User is using to interact with the Relying Party? Can we ensure that each of these devices can provide for a location information? Consequence: the registration information provided by the registration office to the Relying Party and by the Relying Party to the user needs to include one or multiple countries to which that registration is valid. Is that part of the implementing act and applicable technical standard? Now let‘s assume that one country disagrees from a data protection point of view and therefore want’s to de-register the Relying Party: technically easily done, as that specific country is deleted from the list of countries provided by Relying Party. Consequences: Topic 2: Is it possible that a Relying Party situated in a third country (e.g. Switzerland, UK….) can register as a Relying Party? Answer: That must be possible and we have an high interest that this is possible, as this will bring these countries closer to the EU and that‘s a vital interest of all EU member states. Proposal: Similar to the solution in GDPR, the Relying Party has to instruct a representative an register via that representative. Topic 3: How is a registration actually handled? - technically - organizationally - pricing Topic 4: If the Relying Party is requesting information or trust services via a wallet, how to automatically check that the requesting Relying Party is (a) the registered relying party and (b) allowed to ask for the requested information or trust service in the actual business process? - Assumption 1: one (1) Relying Party can have multiple registration for different branches, group companies. - Assumption 2: one (1) Relying Party can have multiple business processes registered with different information requests and/or different trust servieces. Called „variety of use cases“ in recital 17 EU 2024/1183. Topic 5: How to check on a Relying Party registration from another country?

…

On 12. Mar 2025, at 15:16, Alexander Reithoffer ***@***.***> wrote:  Thanks for opening the conversation. I think we can all agree that a Relying Party (RP) needs to register for the specific use case it intends to offer, the type of service it provides, and the data it requires to operate. However, let's consider the regulatory differences across EU member states... If an RP is registered and approved by a regulator in one country, would this automatically grant it recognition across all EU states, or could there be cases where another national regulator requires de-registration due to differences in local laws or policies? How do we handle cross-border regulatory conflicts? What mechanisms should be in place to manage de-registration or re-registration across jurisdictions? Looking forward to hearing your thoughts! — Reply to this email directly, view it on GitHub <#431 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6QDJNXESL6T54PQMU6XYQT2UA6S7AVCNFSM6AAAAABYZHC73WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENBXGU3DQMQ>. You are receiving this because you are subscribed to this thread.

[stefanmore]

(Not an official answer.)

---

Topic 1: Does a registration in one member state is enough to be registered in all member states?

Did anyone state otherwise? Not sure what your question is.

---

Topic 2: Is it possible that a Relying Party situated in a third country (e.g. Switzerland, UK….) can register as a Relying Party?

Your citation suggests otherwise. Art. 5b section 1 eIDAS says: „shall register in the Member State where it is established“. In eIDAS 1 (e.g., for qTSPs) this was done by establishing a legal entity in the EU (see, e.g., Swisscom and SwissSign). (I am not a lawyer, though.)

eIDAS Article 14 covers international aspects, but I think it is only concerned with trust services.

I think this technical discussion thread is not the right place for a regulatory discussion/feedback.

---

Topic 3: How is a registration actually handled?

See the CIR as regards the registration of wallet-relying parties. Details depend on the member state. I think Germany already has some information publicly available.

See also ts5 https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts5-common-formats-and-api-for-rp-registration-information.md

---

Topic 4: If the Relying Party is requesting information or trust services via a wallet, how to automatically check that the requesting Relying Party is (a) the registered relying party and (b) allowed to ask for the requested information or trust service in the actual business process?

a) RP Access Certificate (signature + trust)
b) RP Registration information (RP registration certificate or API)

I think the "multiple departments" and "variety of use cases" question is trickier.
To what extent is this even possible? If the whole company is the legal entity registering as RP, it can retrieve certs for multiple RP Instances (RP Access Cert) and register multiple Use cases (RP Registration Information). Whether the correct registration is used for a use case is another question. However, on detection, the reporting of an RP to the DPA comes to action.

---

Topic 5: How to check on a Relying Party registration from another country?

Do you mean the RP has access to the registration information, or the registration information itself?

For access, the wallet needs to cryptographically verify the RP's access certificate and establish trust in the certificate (via Registrars & Registers trust lists). This should be a unified mechanism for all MS. (Similar to the List of Trusted Lists from eIDAS 1.)

For registration information, the wallet either receives a registration cert (via the RP) or needs to fetch it from an API.

See the CIR as regards the registration of wallet-relying parties and eIDAS Dashboard.

See also ts6 https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts6-common-set-of-rp-information-to-be-registered.md