task1: RP intermediary use case

[peppelinux]

This PR resolves #31

[StefanoContento-tndigit]

Proposing some some suggestions for the file
task1-use-cases/subtask1-2-trust-registry/relying-party-intermediary-use-case.md
and minor comment on
task2-trust-framework/rp-intermediary-openid4vp-technical-report.md

All the suggestions included in my review follow the updates in ARF 3.0.0 compared to ARF 2.8.0

update summary:

1. RP and Relying Party Services

• ARF v2.8.0: Defined the Relying Party (RP) at an organizational level and Relying Party Instances (RPI) at the technical system level. It lacked a formal middle layer to isolate distinct business applications or services within the same organization.

• ARF v3.0.0: Formally introduces the concept of Relying Party Services (Section 3.11.2) to enable separation of concerns. An RP can now register multiple logical Services (each assigned an RP-chosen Relying Party Service Identifier). This prevents different services within the same organization from accessing each other’s data or misusing certificates across different business domains. During registration the RP obtains an individual registration certificate for every service and intendeUse combination. see v1.4 of TS05 Specification of common formats and API for Relying Party Registration information ( WalletRelyingPartyService)

2. RP and RP Intermediary Onboarding

• ARF v2.8.0: Outlined a basic onboarding path where the intermediary registered as an RP and separately registered customer RPs. The framework did not explicitly detail the legal evidence required or the scaling implications on certificates.

• ARF v3.0.0: Significantly expands Section 6.6.5 to detail the onboarding workflow for intermediaries and intermediated RPs:

  • Legally Valid Evidence: Registrars must obtain legally valid proof (e.g., signed contracts, legal mandates, or representative sign-offs) before registering the binding between an intermediary and an intermediated RP.
  • Registry Mapping: The intermediary must register the intermediated RP with its own Registrar. The intermediated RP receives Registration Certificates (WRPRC) that list the intermediary in the usesIntermediary field.
  • Intermediary WRPRC Exclusion: The intermediary receives its own WRPRCs upon initial registration, but ARF v3.0.0 explicitly clarifies that these are not used in intermediated transactions.

3. Wallet-Relying Party Access Certificate (WRPAC)

• ARF v2.8.0: Bound the public key of an RPI to the Relying Party Identifier. For intermediaries, access certificates were standard X.509 certificates carrying the intermediary’s identity.

• ARF v3.0.0:

  • Service Binding: WRPACs now bind the public key to both the Relying Party Identifier AND the Relying Party Service Identifier.
  • Intermediary WRPACs specific for every intermediated RP: Incorporating amended CIR 2025/848 (Annex IV, point 3(k)), an intermediary’s WRPAC must contain an explicit association to the specific intermediated RP on whose behalf it operates. Consequently, an intermediary must manage a separate set of WRPACs for every intermediated RP. Intermediated RPs themselves require no WRPACs.

4. Wallet-Relying Party Registration Certificate (WRPRC)

• ARF v2.8.0: Treated WRPRCs as optional objects issued depending on national Registrar policy.
• ARF v3.0.0:
  • Strict 1:1 Intended Use Mapping: Enforces that each WRPRC contains precisely ONE intendedUseIdentifier (assigned by the Registrar) along with the Relying Party Identifier and Service Identifier. An RP with multiple services and intended uses receives multiple distinct WRPRCs.
  • Intermediary Relationship: For intermediated RPs, the WRPRC explicitly embeds the intermediary's RP Identifier and Service Identifier inside the usesIntermediary structure.

5. Wallet Evaluation in Intermediated Presentation Requests

• ARF v2.8.0 (Section 6.6.3.5.3 / 6.6.5): Required the Wallet Unit to inform the User about the trade names and identifiers of both the Intermediary AND the Intermediated RP during the approval prompt.
• ARF v3.0.0 (Section 6.6.5, Step 4 & 6.6.3.5.3): Major User Interface Shift. The Wallet Unit now displays ONLY the information of the Intermediated RP and its Service to the User during the approval screen. The intermediary's name is hidden from the consent prompt to prevent User confusion, as the citizen interacts solely with the end service. However, the intermediary’s identity is still validated crittographically against the usesIntermediary field in the WRPRC and recorded permanently in the Wallet's Transaction Log.

6. Updates to Annexes and High-Level Requirements (HLRs)

• Annex 2.02 / 2.03 (Topic 44 - Registration Certificates): Updated in v3.0.0 to incorporate the multi-service structure (Relying Party Service Identifier) and mandate the 1:1 relationship between WRPRCs and intended uses.
• Annex 2.02 / 2.03 (Topic 52 - Intermediaries): Updated in v3.0.0 to reflect the new customer-bound WRPAC requirements and the revised dual-identity logging/UI rules (display end-RP name to user, log intermediary).
• Technical Specification References: v3.0.0 references updated technical specifications (such as TS5 v1.0 and ETSI TS 119 472-2 / ETSI TS 119 475) to harmonize JSON/JWT formats, API parameters, and certificate profiles.

[StefanoContento-tndigit]

The example in this section i think that at some point will be updated.
The ETSI TS 119 475 - V1.2.1 at the moment does not contain the information of the service and serviceIdentifier

[StefanoContento-tndigit]

The example in this section i think that at some point will be updated.
The ETSI TS 119 475 - V1.2.1 at the moment does not contain the information of the service and serviceIdentifier

[StefanoContento-tndigit]

@peppelinux I have included some change request but the on-boarding file may require substantial updates. We should discuss this during the next trust group meeting to assess if updates are needed.

[lj-raidiam]

Adds a pilot-baseline note (single default service, serviceIdentifier = 'Null') - defining the baseline for the pilot and a smooth transition from what we currently support toward the full multi-service model, staying TS5 v1.4-compliant (2.4.1).

[peppelinux]

This PR is not compliant with is based on main (ARF 2.9) and the new use case and review comments mixes 2.9 rules with a few 3.0 review edits.

I want to merge it as it is to release 0.8 and then go ahead with 0.9 with the full alignment with ARF 3.0 (see #126)