feat: RPI Architectures and Implementation Scenarios documentation - #31
feat: RPI Architectures and Implementation Scenarios documentation#31peppelinux wants to merge 4 commits into
Conversation
This document proposes three implementation scenarios for Relying Party solutions relying on third party solution (interop gateway/proxy), where only on them appears fully compliant to the profile of RP Intermediary (RPI) as defined in ETSI TS 119 612 and the eIDAS 2.0 regulation. This PR aims to includes detailed requirements, architecture, and sequence diagrams for each scenario. Each of this scenario aims to propose implementation experiences based on real world use case.
Clarified compliance details for RPI scenarios and updated examples.
| ## Scenario 3: RPI Backend | ||
|
|
||
| **Real-world example:** RP outsources trust evaluation, credential verification, and signature validation to specialized backend service. |
There was a problem hiding this comment.
This sounds similar to:
- the AuthZEN approach @leifj shared in https://datatracker.ietf.org/doc/draft-johansson-authzen-trust/
- the Async model scenario in the QTSP docs
There was a problem hiding this comment.
please do a suggestion pointing to that or simply referecing it as a real world framework enabling that
if you/we can
|
|
||
| --- | ||
|
|
||
| ## Scenario 1: RPI Transparent Frontend (eIDAS Model) |
There was a problem hiding this comment.
This sounds similar to the Proxy model scenario in the QTSP docs.
There was a problem hiding this comment.
yeah, it would bring an eidas vanilla solution
|
Thank you for this great summary @peppelinux! This is currently suggested as a draft and as such I think it gives a nice background to scenarios. To take it from draft to something we use in WB it will need to be formalized one step at a time. I would suggest this order.
But with that said I don't see anything wrong in adding it as a draft for the time being. |
This document proposes three implementation scenarios for Relying Party solutions relying on a third party solution (interop gateway/proxy), where only one of them appears fully compliant to the profile of RP Intermediary (RPI) as defined in ETSI TS 119 612 and the eIDAS 2.0 regulation.
This PR aims to include detailed requirements, architecture, and sequence diagrams for each scenario. Each of this scenario aims to propose implementation experiences based on real world use case.
Too properly see the sequence diagram please read the file the "View file" function, as shown below.