feat: RPI impl scenarios#36
Conversation
LeoneRiello74
left a comment
LeoneRiello74
left a comment
There was a problem hiding this comment.
Scenario 2 and 3 requires user engagement for consent on transferring his data, that's solved automatically within the wrprc
| Note over User,SRP: Presentation Flow (OpenID4VP) | ||
|
|
||
| User->>SRP: Request protected resource | ||
| SRP->>SRP: Authentication required |
There was a problem hiding this comment.
which authentication is this one? which information must be used for authentication? In my opinion there should be an oauth token that should be sent by the subordinate to the RPI, so there should be an arrow to RPI before the redirect....
On following scenarios, data is in any cased shared between RPI (as tech provider ) and subordinate. This probably could be managed by a perpetual previous consent provided by the user (that somehow should be presented as reference to the user) or managed within the vp request using an authorization on terms and conditions. If the focus here is trust and privacy, this issue should be highlighted...In the first scenario it's solved by the fact that it has been managed in the wrprc without user engagement.
|
|
||
| ## Overview | ||
|
|
||
| This document describes three implementation scenarios for Relying Party Intermediaries (RPI) where only the first one it the only one that is compliant with the requirements defined in **ETSI TS 119 612 clause 5.5.1** and the **eIDAS 2.0 regulation** (Article 5b(10)). |
There was a problem hiding this comment.
To make the document's purpose even clearer for the reader, could we add a sentence to the overview explaining why these two non-compliant scenarios are being presented? For example, something like:
| This document describes three implementation scenarios for Relying Party Intermediaries (RPI) where only the first one it the only one that is compliant with the requirements defined in **ETSI TS 119 612 clause 5.5.1** and the **eIDAS 2.0 regulation** (Article 5b(10)). | |
| This document describes three implementation scenarios for Relying Party Intermediaries (RPI) where only the first one is compliant with the requirements defined in **ETSI TS 119 612 clause 5.5.1** and the **eIDAS 2.0 regulation** (Article 5b(10)). Scenarios 2 and 3 are described as common architectural patterns that, while valid in other contexts, do not meet the specific legal requirements for **transparency** and **data handling** for an eIDAS 2.0 Intermediary. They are included here to contrast with the compliant model and guide implementation decisions.' |
This would immediately clarify the intent for the reader.
| | **Subordinate RP** | A Relying Party using RPI services to interact with Wallet Instances | | ||
| | **Access Certificate** | Certificate for RP authentication to Wallet Units | |
There was a problem hiding this comment.
Just a minor point for consistency: the doc uses both Wallet Instances and Wallet Units.
| | **RPI** | ✅ Own certificate (RPI_01) | ✅ Own certificate (indicates intermediary role) | | ||
| | **Subordinate RP** | ❌ Not required | ✅ Own certificate (issued via RPI per RPI_03, contains association to RPI per RPRC_04) | | ||
|
|
||
| > **Clarification (per ARF HLLs):** |
There was a problem hiding this comment.
| > **Clarification (per ARF HLLs):** | |
| > **Clarification (per ARF HLRs):** |
Would be best to define HLR to improve readability.
| > - **RPI_01**: An intermediary SHALL register as a Relying Party, obtaining an access certificate containing its own name and unique identifier. | ||
| > - **RPI_03**: An intermediary SHALL register each intermediated Relying Party and receive a registration certificate for each registered intended use. | ||
| > - **RPI_06**: The intermediary SHALL include its own access certificate (RPI_01) and the registration certificate of the intermediated RP (RPI_03) in the presentation request. | ||
| > - **RPRC_04**: The registration certificate contains the 'association to the intermediary' (name and identifier) per CIR 2025/848 Annex I (15). |
There was a problem hiding this comment.
To make this summary more complete, I think we should also mention RPI_07 and RPI_07a, as they are crucial for ensuring the user is fully informed, which is a core principle here.
4 participants
as per conversation here webuild-consortium/wp4-architecture#31