webuild-consortium · peppelinux · Aug 19, 2026 · Jul 15, 2026 · Aug 19, 2026
diff --git a/task1-use-cases/subtask1-1-onboarding/relying_party_onboarding.md b/task1-use-cases/subtask1-1-onboarding/relying_party_onboarding.md
@@ -140,6 +140,8 @@ The Relying Party must provide at least the following when submitting a registra
 - Intended use(s) — one or more records, each specifying: purpose, data requested (credential type, format, and list of claims), privacy policy URL, and supervisory authority / DPA
 - Intermediary reference(s) — zero or more records (identifier, trade name, registry URI); required if the wallet-relying party relies on an intermediary
 - Intermediary flag — indication if the wallet-relying party acts as an intermediary for other relying parties
+
+See [UC-RPI-01 — Relying Party Intermediary](../subtask1-2-trust-registry/relying-party-intermediary-use-case.md) for intermediated presentation flows.
 - Attestation type(s) — for provider/issuer entitlements: one or more records, each specified either by a catalogue URL provided by WP4 (default/baseline option) or a self-declaration of the attestation schema
 - Economic activity (optional) — NACE Rev.2 code with optional national scheme (e.g. ATECO); used for sector policy templates and register routing. See [Entity and Service Taxonomy](../../task5-participants-policies/entity-service-taxonomy.md).
 - Service classification (optional) — UN CPC code for the digital service offered; complements `srvDescription` and intended use.

diff --git a/task1-use-cases/subtask1-2-trust-registry/README.md b/task1-use-cases/subtask1-2-trust-registry/README.md
@@ -19,6 +19,7 @@ These use cases are aligned with the [EUDI Wallet Architecture and Reference Fra
 | **UC-TE-02** | [Wallet Unit evaluates Credential Issuer](wallet-unit-evaluates-credential-issuer.md) | Wallet Unit verifies PID/Attestation Provider before requesting PID or attestation |
 | **UC-TE-03** | [Credential Issuer evaluates Wallet Unit](credential-issuer-evaluates-wallet-unit.md) | PID/Attestation Provider verifies WIA and KA before issuing |
 | **UC-TE-04** | [Wallet Unit evaluates Relying Party](wallet-unit-evaluates-relying-party.md) | Wallet Unit verifies RP before presentation |
+| **UC-RPI-01** | [Relying Party Intermediary](relying-party-intermediary-use-case.md) | Intermediary presents on behalf of another RP; dual-identity wallet evaluation |
 | **UC-TE-05** | [Relying Party evaluates presented credentials](relying-party-evaluates-credentials.md) | RP validates PID and attestation signatures using Trusted Lists |
 | **UC-TE-06** | [Trusted List discovery and consumption](trusted-list-discovery-consumption.md) | Obtaining and using LoTL and Trusted Lists for validation |
 

diff --git a/task1-use-cases/subtask1-2-trust-registry/relying-party-intermediary-use-case.md b/task1-use-cases/subtask1-2-trust-registry/relying-party-intermediary-use-case.md
@@ -0,0 +1,141 @@
+# Use Case UC-RPI-01: Relying Party Intermediary
+
+## Scope
+
+An **Intermediary** is a Relying Party that requests attribute presentation from a Wallet Unit **on behalf of** another registered Relying Party (the **intermediated RP**). Typical examples: identity/interop gateways, sector platforms, or SaaS verifiers that serve multiple service providers.
+
+This use case covers registration, intermediated remote presentation (OpenID4VP), and wallet-side trust evaluation. Protocol details and JSON examples: [RPI OpenID4VP technical report](../../task2-trust-framework/rp-intermediary-openid4vp-technical-report.md).
+
+## Actors
+
+| Actor | Role |
+| ----- | ---- |
+| **Intermediary** | Registers as RP with `isIntermediary`; holds **WRPAC**; sends presentation requests |
+| **Intermediated RP** | Registered at a Registrar; may hold **WRPRC** per intended use; instructs intermediary what to request |
+| **Registrar** | Registers both parties; records `usesIntermediary` relationship (RPI_04) |
+| **Access CA / WRPRC Provider** | Issues WRPAC to intermediary; WRPRC to intermediated RP |
+| **Wallet Unit** | Authenticates intermediary; displays both identities; evaluates intermediated RP entitlements |
+| **Holder (User)** | Approves or denies presentation |
+
+## Goal
+
+- **Business**: Allow service providers to use a trusted third-party verifier without each holding a direct wallet connection, while keeping the User informed of **both** the technical caller and the service consuming the data.
+- **Technical**: Intermediary authenticates with its WRPAC; intermediated RP identity and authorisation travel in `verifier_info`; wallet validates both per ARF Topic 52.
+
+## Scenarios
+
+| ID | Scenario | Intermediated? |
+| -- | -------- | -------------- |
+| **S1** | Interop gateway requests PID for a cinema booking service | Yes |
+| **S2** | Intermediary requests attributes for its **own** service | No (direct RP) |
+
+### S1 — Intermediated presentation (primary)
+
+**Example:** *VerifyNow* (intermediary) requests age verification on behalf of *Example Cinema Ltd.* (intermediated RP).
+
+**Preconditions**
+
+- Intermediary registered with `isIntermediary: true` and valid **WRPAC**.
+- Intermediated RP registered; intended use and optional **WRPRC** issued; `usesIntermediary` points to the intermediary (RPI_04).
+- Intermediated RP provided the intermediary with: trade name, identifier, Registrar URL, intended-use id, attribute list, optional WRPRC reference (RPI_05).
+
+**Main flow**
+
+```mermaid
+sequenceDiagram
+    participant IRP as Intermediated RP
+    participant INT as Intermediary
+    participant W as Wallet Unit
+    participant U as User
+
+    IRP->>INT: Request attributes (RPI_05 metadata)
+    INT->>W: OpenID4VP Request Object<br/>(INT WRPAC + IRP verifier_info)
+    W->>W: Detect intermediation (RPI_07)<br/>Validate INT WRPAC + IRP WRPRC/registry
+    W->>U: Show Intermediated RP names + ask user for consent
+    U->>W: Approve or deny
+    W->>INT: Authorization Response (response_uri)
+    INT->>IRP: Forward attributes (RPI_08/09) 
+    INT->>INT: delete attributes after use (RPI_10)
+```
+
+1. Intermediated RP instructs the intermediary (RPI_05).
+2. Intermediary builds and signs the OpenID4VP Request Object with its **WRPAC**; includes intermediated RP `registrar_dataset` and optional `registration_cert` in `verifier_info` (RPI_06, RPRC_19a).
+3. Wallet detects an intermediated presentation when WRPAC `organizationIdentifier` ≠ `registrar_dataset.identifier` (RPI_07).
+4. Wallet validates intermediary WRPAC (Access CA TL) and intermediated RP WRPRC/registry entitlements ([UC-TE-04](wallet-unit-evaluates-relying-party.md)).
+5. Wallet displays **both** trade names; User approves (RPA_07).
+6. If User opted to verify registration, Wallet checks intermediary–RP relationship via WRPRC `intermediary` field (RPRC_04) or Registrar API (RPI_07a).
+7. Wallet sends response to intermediary `response_uri`; intermediary forwards to intermediated RP.
+
+**Postconditions (success)**
+
+- The wallet does not display the information of the intermediary and its Service to the User before asking for  consent. Only the information of the intermediated RP are shown. The intermediary name and service are logged by the Wallet Unit. 
+- Attributes disclosed only match intermediated RP registered entitlements (RPRC_21).
+- Intermediary deletes received credentials immediately after forwarding (RPI_10).
+
+### S2 — Intermediary as direct Relying Party
+
+An entity registered as intermediary may also act **in its own capacity** (RPI_01 note c): WRPAC and `verifier_info` refer to the **same** party. Flow matches [UC-TE-04](wallet-unit-evaluates-relying-party.md) without dual-identity handling.
+
+## Onboarding (summary)
+
+Both the Intermediary and the Intermediated RP are considered RP. The onboarding process shall follow the detailed steps in: [Relying Party Onboarding](../subtask1-1-onboarding/relying_party_onboarding.md).
+The following table highlight the on-boarding step differences between Intermediary and Intermediated RP
+| Step | Intermediary | Intermediated RP |
+| ---- | ------------ | ---------------- |
+| Register | As RP with `isIntermediary: true` (RPI_01, Reg_26) | At Registrar in establishment MS (RPI_03) |
+| Relationship | — | Provide evidence of intermediary use; Registrar sets `usesIntermediary` (RPI_04) |
+| Certificates | **WRPAC** (mandatory); own WRPRC only for direct use (S2) | **WRPRC** per intended use; includes `intermediary` association (RPRC_04) |
+| Registry API | May register intended uses on behalf of WRP ([TS5 notes](../../task5-participants-certificates-policies/ts5-registry-api-and-data-formats.md)) | — |
+
+**Note:** Intermediated RPs do **not** need a WRPAC (ARF §6.6.5).
+
+## Wallet evaluation checklist
+
+| Check | Source | Applies to |
+| ----- | ------ | ---------- |
+| WRPAC chain + revocation | Access CA TL | Intermediary |
+| Intermediation Detection | WRPAC from intermediary differs from verifier_info | Both|
+| Request Object Signature | public key contained in x5c | Intermediary |
+| WRPAC chain + revocation | Access CA TL | Intermediary |
+| WRPRC signature + entitlements | WRPRC Provider TL / registry | Intermediated RP |
+| Requested attributes ⊆ registered | RPRC_21 | Intermediated RP |
+| Only Intermediated RP displayed | RPI_07 | Intermediated RP|
+| Relationship registered | 6.6.5 ARF | Intermediary ↔ Intermediated RP |
+| EDP (if present) | EDP_02/03 | Evaluate against **intermediated** RP id/root, not intermediary WRPAC |
+
+## Success criteria
+
+- Intermediary authenticated via valid WRPAC.
+- Intermediated RP identity and entitlements verified (WRPRC or registry).
+- User informed only of Intermediated RP informations before consent.
+- Intermediated transaction does not expose intermediary WRPRC in `verifier_info`.
+
+## ARF requirements (key)
+
+| ID | Summary |
+| -- | ------- |
+| RPI_01 | Intermediary registers as RP; obtains WRPAC |
+| RPI_03 | Intermediary registers each intermediated RP |
+| RPI_04 | Registrar verifies and records intermediary relationship |
+| RPI_05 | Intermediated RP supplies request metadata to intermediary |
+| RPI_06 | Intermediary sends request with own WRPAC + IRP data/WRPRC |
+| RPI_07 | Wallet detects and displays only intermediated RP identity |
+| Topic 52  | Wallet verifies registered relationship when User requests |
+| RPI_08–10 | Forwarding, verification, immediate deletion by intermediary |
+| RPRC_04 | Intermediated WRPRC contains intermediary association |
+
+Full matrix: [Trusted List / Registration / Trust Evaluation Matrix](../../task2-trust-framework/trusted-list-registration-trust-evaluation-matrix.md) §7.
+
+## Out of scope (this use case)
+
+- Proximity presentation (ISO 18013-5 / TS 119 472-2 clause 5.3) — see technical report §12
+- Architecture-group implementation scenario variants ([architecture PR #31](https://github.com/webuild-consortium/architecture/pull/31))
+
+## References
+
+- [Consolidated Terms — Intermediary](../terms-and-entities.md#316-intermediary)
+- [RPI OpenID4VP technical report](../../task2-trust-framework/rp-intermediary-openid4vp-technical-report.md)
+- [EUDI Wallet Trust and Entitlement Discovery](../../task2-trust-framework/eudi-wallet-trust-and-entitlement-discovery.md)
+- [WRPRC Example 3 — With Intermediary](../../task5-participants-policies/relying_party_registration_certificate.md)
+- [Embedded Disclosure Policies](../../task5-participants-policies/embedded-disclosure-policies-implementation.md)
+- [ARF Topic 52 — Relying Party intermediaries](https://eudi.dev/2.9.0/annexes/annex-2/annex-2.02-high-level-requirements-by-topic/#a2330-topic-52-relying-party-intermediaries)
diff --git a/task1-use-cases/subtask1-2-trust-registry/wallet-unit-evaluates-relying-party.md b/task1-use-cases/subtask1-2-trust-registry/wallet-unit-evaluates-relying-party.md
@@ -4,6 +4,8 @@
 
 Before the User approves **presentation** of attributes to a Relying Party, the Wallet Unit evaluates the Relying Party: it verifies the RP's access certificate using the **Access Certificate Authority Trusted List**, checks that **certificates are not revoked**, and optionally verifies the RP's **registration** (and requested attributes) via registration certificate or **Registrar registry**, so the User can make an informed decision.
 
+For **intermediated** presentation (intermediary acting on behalf of another RP), see [UC-RPI-01 — Relying Party Intermediary](relying-party-intermediary-use-case.md).
+
 ## Actors
 
 - **Primary**: Wallet Unit (on behalf of the Holder)

diff --git a/task2-trust-framework/README.md b/task2-trust-framework/README.md
@@ -12,7 +12,7 @@ This task defines the conceptual trust framework for the WP4 Trust Infrastructur
 - **`trusted-list-registration-trust-evaluation-matrix.md`** – Requirements matrix for trusted lists, participant registration and trust evaluation derived from EUDI Wallet ARF Annex 2
 - **`trust-infrastructure-schema.md`** – Structural schema of the trust infrastructure, including registries, entities and relationships
 - **`eudi-wallet-trust-and-entitlement-discovery.md`** – Policy discovery and trust verification from wallet (holder) perspective: WRPRC/WRPAC discovery, Trusted List validation, Registry lookup, entitlement and attribute validation (ARF RPRC_21, RPA_*)
-- **`rp-intermediary-openid4vp-technical-report.md`** – Non-normative technical report on Relying Party intermediaries in remote OpenID4VP flows: `verifier_info`, WRPAC/WRPRC exposure, intermediary detection, and examples (ARF Topic 52, ETSI TS 119 472-2)
+- **`rp-intermediary-openid4vp-technical-report.md`** – Non-normative technical report on Relying Party intermediaries in remote OpenID4VP flows: `verifier_info`, WRPAC/WRPRC exposure, intermediary detection, and examples (ARF Topic 52, ETSI TS 119 472-2). Use case: [UC-RPI-01](../task1-use-cases/subtask1-2-trust-registry/relying-party-intermediary-use-case.md).
 - **`issue-mdl-pub-eaa-discovery.md`** – Issue note on mDL, EAA publication and discovery in relation to the trust framework
 - **`etsi-identifier-handling.md`** – Handling of ETSI identifiers and their mapping into the trust infrastructure
 

diff --git a/task2-trust-framework/rp-intermediary-openid4vp-technical-report.md b/task2-trust-framework/rp-intermediary-openid4vp-technical-report.md
@@ -5,7 +5,7 @@
 | **Status** | Draft technical report (non-normative) |
 | **WP4 task** | Task 2 — Trust Framework |
 | **Scope** | EUDI Wallet remote presentation; Relying Party intermediaries; WRPAC / WRPRC trust evaluation |
-| **Related WP4 docs** | [Entities Involved](entities-involved.md), [EUDI Wallet Trust and Entitlement Discovery](eudi-wallet-trust-and-entitlement-discovery.md), [Trust Infrastructure Schema](trust-infrastructure-schema.md), [Consolidated Terms — Intermediary](../task1-use-cases/terms-and-entities.md#316-intermediary) |
+| **Related WP4 docs** | [UC-RPI-01 — Relying Party Intermediary](../task1-use-cases/subtask1-2-trust-registry/relying-party-intermediary-use-case.md), [Entities Involved](entities-involved.md), [EUDI Wallet Trust and Entitlement Discovery](eudi-wallet-trust-and-entitlement-discovery.md), [Trust Infrastructure Schema](trust-infrastructure-schema.md), [Consolidated Terms — Intermediary](../task1-use-cases/terms-and-entities.md#316-intermediary) |
 | **Primary normative sources** | OpenID4VP 1.0, OpenID4VC-HAIP, ETSI TS 119 472-2, ETSI TS 119 475, EUDI ARF v2.9.0 (Topic 44, Topic 52, Topic X) |
 
 ---
@@ -115,7 +115,7 @@ Topic X (revision round) describes the registration-side model:
 - Intermediated Relying Party registry data include `usesIntermediary`.
 - Intermediated RP WRPRCs contain the intermediary's RP identifier (RPRC_04).
 - During a transaction, the intermediary sends its WRPAC plus the intermediated RP's WRPRC and identifier in the request.
-- Evolution: with Relying Party Services, Service identifiers for both intermediary and intermediated RP may also be required.
+- Evolution: with Relying Party Services, Service identifiers for both intermediary and intermediated RP may also be required. Under TS5 v1.4, a Relying Party (WalletRelyingParty) registers one or more services (walletRelyingPartyService). Each service defines its own serviceIdentifier, serviceTradeName, intendedUse, and usesIntermediary array. Intermediation is bound at the service level: an Intermediated RP specifies which Intermediary service (WalletRelyingPartyService) it relies upon for a specific business flow. During a transaction, the Wallet evaluates both the RP identifier + serviceIdentifier from the Intermediary's WRPAC against the Intermediated RP's registrar_dataset / WRPRC.
 
 ---
 
@@ -385,11 +385,10 @@ When the intermediary interacts with the Wallet **for its own service** (RPI_01
 | **RPI_01** | Intermediary registers as RP; obtains WRPAC; optional own WRPRC **not used** in intermediated transactions. |
 | **RPI_03** | Intermediary registers each intermediated RP; may hold intermediated RP WRPRCs. |
 | **RPI_05** | Intermediated RP instructs intermediary what to include in the request. |
-| **RPI_06** | Intermediary sends request with own WRPAC + intermediated RP data/WRPRC. |
-| **RPI_07** | Wallet detects intermediation via identity mismatch; displays both parties. |
-| **RPI_07a** | Wallet verifies intermediary–RP relationship (WRPRC or Registrar). |
+| **RPI_06** | Intermediary sends request with specific a WRPAC (may have more than one WRPAC for every intermediated Relying Parties Service, see Reg_34a ) and the related intermediated RP data/WRPRC. |
+| **RPI_07** | Wallet detects intermediation via identity mismatch; displays to users only intermediated RP info. |
 | **RPRC_04** | Intermediated RP WRPRC contains intermediary association. |
-| **RPRC_19 / 19a** | Registration data and WRPRC included in presentation request extension. |
+| **RPRC_19** | Registration data and WRPRC included in presentation request extension. The WRPRC is specific to the Service and intended use. |
 | **RPRC_20a** | OpenID4VP / ISO 18013-5 extension for RPRC_19a transport (`verifier_info`). |
 
 ---
@@ -399,7 +398,7 @@ When the intermediary interacts with the Wallet **for its own service** (RPI_01
 | Item | Notes |
 |------|-------|
 | Proximity flow (`ISO 18013-5` `euWrpRegistrarInfo` / `euWrprc`) | Parallel extension model in ETSI TS 119 472-2 clause 5.3; not covered in this report. |
-| Topic X RR — Relying Party Service identifiers | May extend `registrar_dataset` with Service IDs for both intermediary and intermediated RP. |
+| Topic X RR — Relying Party Service identifiers | May extend `registrar_dataset` with Service IDs for both intermediary and intermediated RP.  See TS5 v1.4 alignment for WalletRelyingPartyService|
 | IA vs ETSI field alignment | Implementing Act drafts reference `tradeName`; ETSI TS 119 472-2 v1.2.1 uses `srvDescription` — align when IA is final. |
 | WEBUILD trust evaluation matrix | Intermediated flows may require additional matrix rows for dual-identity validation; see [Trusted List Registration Trust Evaluation Matrix](trusted-list-registration-trust-evaluation-matrix.md). |
 | Embedded disclosure policies (EDP_02, EDP_03) | When RP is intermediary, Wallet compares authorised identifiers / roots of trust against **intermediated** RP data from the request or WRPRC, not the intermediary WRPAC. |