Relying Party Services — Intermediary Relationships

[rfbonte]

Context

The ETD Herkenningsmakelaar is a regulated role in the Dutch Electronic Access Services framework. It is not equivalent to an eIDAS Intermediary. Article 5b(10) of the revised eIDAS Regulation refers to intermediaries acting on behalf of Relying Parties, but does not define the same role, responsibilities or governance model as ETD.

The current direction is to use service information registered in the European Relying Party Register rather than to retain HerkenningsmakelaarId for compatibility with an earlier WE BUILD Service Catalogue proposal.

Working document:
https://github.com/rfbonte/wp4-trust-group/blob/rfbonte-services-upgrade-for-authorisations/task5-participants-certificates-policies/services-upgrade-for-authorisations.md

AI assistance: Drafted and edited with the assistance of ChatGPT (OpenAI). The author remains responsible for review, source verification and conclusions - review is still in process

Problem Statement

The Relying Party Register may need to represent that a Relying Party or Service uses an Intermediary. That does not justify importing the ETD Herkenningsmakelaar role or introducing an undefined generic “ecosystem intermediary”.

The required relationship, authority, lifecycle, registration and certificate implications must be determined using wallet and eIDAS terminology.

Current Direction

• Do not treat the ETD Herkenningsmakelaar and eIDAS Intermediary as equivalent.
• Do not retain HerkenningsmakelaarId merely for ETD compatibility.
• Do not introduce an additional “ecosystem intermediary” role without a clear legal and architectural basis.
• Start from the existing wallet concepts usesIntermediary and isIntermediary.
• Determine whether an Intermediary relationship must be registered at Relying Party level, Service level or both.
• Align the result with the existing WE BUILD endpoint-lookup decision and the applicable certificate and authorisation flows.

Questions

• What authority does an Intermediary have to act for a Relying Party or one of its Services?
• How is that relationship registered, verified, changed and withdrawn?
• Which identifiers are used for the Relying Party, Service and Intermediary?
• Which Registration Certificate or Access Certificate relationships are affected?
• Which information must a user, Wallet or issuer of an Authorisation Attestation be able to determine?
• How does the result align with the WE BUILD endpoint-lookup architecture?

Related Decision

WE BUILD endpoint lookup service ADR

Expected Outcome

A wallet-native and legally supportable model for Intermediary relationships, without assuming equivalence with the ETD Herkenningsmakelaar.

Priority

P2 – Required for future interoperability and any pilot flow that uses an Intermediary.

[esthermakaay]

One of the key differences between a "Herkenningsmakelaar" and "Intermediary" is the legal context:

• eIDAS does NOT define or regulate the role of intermediary. It only states (art 5b (10)) "Intermediaries acting on behalf of relying parties shall be deemed to be relying parties and shall not store data about the content of the transaction". (This is a headache in and of its own, because it leaves room for the Member States to add criteria through the RP registration on "intermediaries" and we're seeing the first examples of that already.)
• eHerkenning DOES regulate and define this role and it's very specific on its responsibilities (and an RP can only connect through this role).
  So even if it "smells" similar, it is not and we cannot presume a formal relationship between these roles.

On top of this, you're introducing a 3rd role that is not explicit in the eIDAS legislation: "ecosystem intermediary". Be very careful about introducing concepts that are not supported in eIDAS anywhere, since we're building use cases that should work within the full eIDAS ecosystem and not within a proprietary sub-ecosystem.

That also applies to the concept of "service catalogues".

Within specific (regulated) non-eIDAS ecosystems, it is possible to developed a scoped set of additional concepts ("ecosystem intermediary", "service catalogue"), but that specific ecosystem/domain should be clearly governed (and not "drafted up as examples" in the use cases). Within such a specific ecosystem there can be rules and guidelines on how to work with eIDAS and implement the roles and services from eIDAS within the specific ecosystem (and apply more fine-grained rules that only are applicable within the limited scope). It will not be done from the eIDAS legislation or ecosystem.

[rfbonte]

Hi @esthermakaay, thank you for your response. I agree completely, although I need to think a bit longer on your comment regarding me introducing a 3rd role "ecosystem intermediary".

Regarding the last part of your comment:
For now I have done a quick and dirty design reusing the ETD Service Catalgue.
For me a better way would be to re-use the wallet relying register and registration certificates, if this is possible. I created issue 279 for this. #279

[lalc]

I don't seem to have access to the link shared.

As for the service catalogue and lookup services within WEBUILD, from WP4, we have a decision from Amsterdam to create a service lookup for wallet-wallet, Issuer-Wallet, and RelyingParty-Wallet interactions.

Copying: @endimion

[rfbonte]

I don't seem to have access to the link shared.

https://github.com/webuild-consortium/BU4/tree/main/ServiceCatalogue, currently in pull request 13
This is in the BU4 repository, you need access (ask Boris Lingl - boris.lingl@datev.de)

[rfbonte]

The issue body has been updated to reflect the current analysis and the existing discussion. It no longer assumes equivalence between the ETD Herkenningsmakelaar and an eIDAS Intermediary and now starts from the wallet concepts usesIntermediary and isIntermediary.

Working document: https://github.com/rfbonte/wp4-trust-group/blob/rfbonte-services-upgrade-for-authorisations/task5-participants-certificates-policies/services-upgrade-for-authorisations.md

Review is still in process.

[Saramandus]

Thank you for raising this, @rfbonte There is ongoing work on clarifying the role of intermediaries in #185 and additions to the Blueprint appendix on Trust #90 that will hopefullyl answer most of the questions.

You are correct that we should avoid introducing proprietary terminology (like ETD's Herkenningsmakelaar) or vague generic terms when defining the role of intermediaries. The eIDAS framework and its supporting regulations already provide the exact terminology, legal relationships, and certificate implications we need:

• Legal Role & Terminology: Under eIDAS Article 5b(10), intermediaries acting on behalf of relying parties are formally deemed to be relying parties themselves
• Registration & Certificate Association: The newly published Implementing Regulation (EU) 2026/1730 (amending EU 2025/848 Annex I, point 16) explicitly introduces the requirement to register the cryptographic and organizational 'association' between the intermediary (who holds the Access Certificate - WRPAC) and the underlying Relying Party (the recent CIR updates and how we deal with them within the WB scope are worked on in Updated CIR info #291 )
• I believe WE BUILD already implements this exact pattern in our Pilot Design (D3.1) and Trust Infrastructure. This is not my main expertise and others are welcome to correct me but my understanding is that during OID4VP presentation flows, the intermediary uses its Access Certificate, and the relation to the intermediated RP is validated via the "Member State Registrar", allowing the wallet to display both names to the user (e.g., 'Requestor: [Intermediary] on behalf of: [RP]')

Conclusion: Our current architecture is aligned with the official eIDAS and wallet-specific terminology specified in CIR and I do not see that new intermediary roles or concepts need to be created in our specs. Please reopen this is issue if I completely missed the point, and if so please specify as shortly as possible the requirement focusing on what you are missing in the current setup and we can make sure you get a better response. :)