Create IntermediaryTesting.md#30
Conversation
First draft of Intermediary testing proposal
| @@ -0,0 +1,538 @@ | |||
| # 1 Abstract | |||
|
|
|||
| Relying Party Intermediaries serve as trusted intermediaries between Relying Parties and Wallet Holders, simplifying the integration of EUDIW capabilities while maintaining security and trust guarantees. | |||
There was a problem hiding this comment.
| Relying Party Intermediaries serve as trusted intermediaries between Relying Parties and Wallet Holders, simplifying the integration of EUDIW capabilities while maintaining security and trust guarantees. | |
| Relying Party Intermediaries (RPI) serve as trusted intermediaries between Relying Parties and Wallet Holders, simplifying the integration of EUDIW capabilities while maintaining security and transparency. |
There was a problem hiding this comment.
No problem to add the abbreviation, however, transparency is something completely different then trust guarantees. You can be completely transparent but still deliver something that is not trustworthy at all. E.g. if you deliver EAA that are not sealed, it is impossible to verify the integrity. But you can provide that unsealed EAA in full transparency.
|
|
||
| Relying Party Intermediaries serve as trusted intermediaries between Relying Parties and Wallet Holders, simplifying the integration of EUDIW capabilities while maintaining security and trust guarantees. | ||
|
|
||
| There are a number of critical technical challenges for RPI implementation, particularly around dual identification (distinguishing between the intermediary and the actual RP) and embedded disclosure policy evaluation. In order to ensure that the EUDIW implementations will allow for Intermediaries to play their role, Intermediaries should be tested in WE BUILD. These challenges require availability of certain infrastructure components and testing scenarios within the WE BUILD large scale pilot. |
There was a problem hiding this comment.
May we would like to introduce a reference to ETSI TS 119 461 here, about the TSP identity proofing?
about RPI registration phase, requiring id proofing, see: https://github.com/webuild-consortium/wp4-trust-group/blob/7f74edb200220206a3b5c626c6d5e3aba7897f55/task2-trust-framework/wallet-policy-discovery.md#23-wrprc-provider-and-registration-certificate-issuance
I would continue contributing on this chapter before taking in trust group all about RPI
There was a problem hiding this comment.
ETSI TS 119 461 is related to the identification of the natural person. Here we talk about identification of the RPI and the RP). So, ETSI TS 119 461 is not relevant here.
The 2.3 WRPRC Provider and Registration Certificate Issuance you refer to speaks about ETSI TS 119 475. That one is relevant and could be mentioned indeed.
|
|
||
| ## 2.2 The RP Intermediary Role | ||
|
|
||
| As defined in draft ETSI TR 119 479-1, an RP Intermediary is: |
There was a problem hiding this comment.
I would not rely a technical reports for the definitions of the main actors, don't we have a specification instead of a technical report?
There was a problem hiding this comment.
I don't see why a Technical Report would not be a good reference. It is also an official ETSI document. But instead of a document that gives requirements, it gives clarifications. More relevant is that it is not yet published (the report is in remote approval process right now and if the result is positive, it should get published early May).
|
|
||
| “A party that provides a service to Relying Parties related to the handling of the interaction with wallets (a.o. EUDIWs) or other solutions for identification, authentication or attribute attestation of persons.” | ||
|
|
||
| RP Intermediaries are also commonly referred to as “identity brokers” in existing electronic identification schemes. Their role is to abstract the complexity of wallet interactions, protocol implementations, and attestation validation, providing a unified interface for Relying Parties. |
There was a problem hiding this comment.
I would not use the term broker, since when a party deals with a broker (under its will) it definitively trusts the broker.
in our scenario, the wallet instace interacts with a RPI while trusts only the trusted registries and the trust anchors provided by trusted registries.
the term identity broker is also not properly regulated, while it brings evident sematic concerns.
I would may spend the term identity broken only for some sort of identity provider aggregator, definitively not for RPs, since the RPs don't provide digital identities (but requests them for the scopes of auth/authz).
There was a problem hiding this comment.
For me it is OK to remove the reference to identity brokers. I just mentioned it for people to easier understand. But that is how a lot of the parties that want to become RPI are already referred to today (Signicat, etc.).
Not really on the change proposed, a reaction to your comment about trust: In my opinion the RP will also need to trust the RPI. I don't agree that the RP necessarily will still interact with the trusted registries and the trust anchors. That will depend on the level of the service provided by the RPI. Part of that service can (in in my opinion in most cases, will) be the validation of PID, EAA, etc. So, that means that the RPI will need to deal with the trusted registries and the trust anchors. Even if that part is done by the RP (which is another value proposition), the RPI is the one that will need to verify that the EUDIW is trustworthy and the RP will need to trust the RPI to do that correctly.
| Draft ETSI TR 119 479-1 identifies four key benefits that RP Intermediaries bring to the EUDIW ecosystem: | ||
|
|
||
| ## 3.1 Inclusion | ||
|
|
||
| Small and medium enterprises (SMEs) and organizations without dedicated identity specialists will struggle to implement EUDIW integration independently. RP Intermediaries enable these organizations to participate in the digital identity ecosystem without requiring specialized in-house expertise. | ||
|
|
||
| **Impact:** Without RP Intermediaries, a significant digital divide would emerge between organizations with substantial IT resources and those without, limiting the reach and effectiveness of the EUDIW initiative. | ||
|
|
||
| ## 3.2 Speed of Adoption | ||
|
|
||
| The scarcity of identity and cybersecurity specialists creates a bottleneck for EUDIW implementation. Organizations already integrated with an RP Intermediary can begin using EUDIW capabilities immediately once their intermediary supports it, rather than queuing for specialist resources. | ||
|
|
||
| **Impact:** RP Intermediaries break the “chicken and egg” problem by enabling rapid scaling of Relying Party adoption, which in turn increases wallet holder incentives to obtain and use EUDIWs. | ||
|
|
||
| ## 3.3 Cost Efficiency | ||
|
|
||
| Building and maintaining interfaces and configurations for 27+ national EUDIW implementations represents substantial development and operational costs. RP Intermediaries amortize these costs across multiple Relying Parties. | ||
|
|
||
| **Cost Analysis:** |
There was a problem hiding this comment.
this is quite promotional for the solution
if the scope of this PR is the introduction of the RPI within the architecture from a techncial perspective, I would simply move these promotional consideration to a separate document (white paper?)
There was a problem hiding this comment.
It is already in the white paper I uploaded earlier. For me OK to remove.
| Organizations lacking identity specialists may implement EUDIW integration with suboptimal security and privacy controls, especially when under regulatory deadline pressure. RP Intermediaries can provide: | ||
|
|
||
| - Proven, audited implementation patterns | ||
|
|
||
| - State-of-the-art security controls | ||
|
|
||
| - Expert guidance and support | ||
|
|
||
| - Consistent privacy protection mechanisms |
There was a problem hiding this comment.
I suppose that we may not try to sell to the users an IT externalization strategy through this document.
| - Consistent privacy protection mechanisms | ||
|
|
||
|
|
||
| **NOTE**: Although Intermediaries have the potential to deliver these benefits, there is no guarantee that they will. Although the will have a crucial role regarding trust and security, there is currently no obligation for intermediaries to follow security best practices, let alone that they would be audited by independent auditors. Draft ETSI TR 119 479-1 recognizes this issue and proposes ETSI to develop a standard for Policy |
There was a problem hiding this comment.
is there some interest in mentioning the NIS2 directive and in particular any obligation for public and private digital service suppliers for the public service organizations?
There was a problem hiding this comment.
Will an RPI be under NIS2? I'm not so sure. Officially it is not a TSP and it is not so clear under NIS2 entities it would fall. I do think that NIS2 is applicable, but I'm not sure, so I would prefer not to mention it.
|
|
||
| ## 4.1 Interaction Model | ||
|
|
||
| The RPI acts as a complete proxy between the Relying Party and the wallet: |
There was a problem hiding this comment.
I would not entirely rely upon the concept of proxy
an intermediary could act, technically, as a proxy (masquerating) or like a gateway (keeping transaction transparents)
from an architecturale perspective, I would like to explore and explode this concept more
There was a problem hiding this comment.
What do you propose in terms of change to the text?
|
|
||
| - RPI transforms attributes to RP-specific format | ||
|
|
||
| - No direct wallet-to-RP communication |
There was a problem hiding this comment.
| - No direct wallet-to-RP communication | |
| - No direct wallet-to-RP communication |
it may depends by the techncial solution implemented
there might be RPI acting as intermediaries only for trust evaluation, and about to multiple trust frameworks, provding then the endpoints of the subordinate RPs directly
There was a problem hiding this comment.
in the previous example, for instance, the RPI could provide onyl the respnse endpoint, handling the trust eval to the credential issuers invoned in the vp tokens, making the subordinates RP able to egage the presentation flow directly with the wallets (using their own auth endpoint)
| 2. **RPI generates wallet presentation request** | ||
|
|
||
|
|
||
| - Interacts with the user to initiate the EUDIW communication |
There was a problem hiding this comment.
the wallet interacts with the user, the RP though the wallet
There was a problem hiding this comment.
The RPI will show the QR code to the user. So, it interacts with the user. The RP will not interact with the wallet at all. That will be again the RPI in a later stage.
| - Translates RP requirements to wallet protocol (OpenID4VP, etc.) | ||
|
|
||
|
|
||
| 3. **Wallet holder accepts EUDIW communication** |
There was a problem hiding this comment.
we should mention the evaluation of both the access certificate and the registration(s) certificate, see (an review if possible): https://github.com/webuild-consortium/wp4-trust-group/blob/7f74edb200220206a3b5c626c6d5e3aba7897f55/task2-trust-framework/wallet-policy-discovery.md
|
|
||
| ### 4.2.2 Data Minimization and Privacy | ||
|
|
||
| RP intermediaries need to treat a high amount of privacy sensitive information. According to eIDAS 2 they are not allowed to store that data. |
There was a problem hiding this comment.
this is very singular
one of the most tangible benefits of using an intermediary, thorugh a public or private supplier, is also about the log retention and any other about non repudiability of the transaction happend
organization that requires their suppliers to care about the eidas log retention policies would therefore use intermediaries in the techncial form of pure RP and not eIDAS RPI, due to these limitations.
|
|
||
| - **No Persistent Storage**: Attribute data must be processed in-memory only | ||
|
|
||
| - **Selective Disclosure**: RPI should request and forward only required attributes |
There was a problem hiding this comment.
we should also mention that RPI should provide the WRPRCs as well.
|
|
||
| ### 4.3.1 Trust Service Provider Status | ||
|
|
||
| Draft ETSI TR 119 479-1 Annex B states that RP intermediaries have an important trust role, and as such should be considered similar to a Trust Service Provider. This recognition suggests that RPIs should at least meet security and policy requirements comparable to other TSPs. ETSI EN 319 401 (General Policy Requirements for Trust Service Providers) is a minimal basis. WE BUILD could deliver additional requirements adapted to the specific case of RPIs to ETSI for inclusion in a standard on the topic. |
There was a problem hiding this comment.
a statement of a technical report would not be used as a normative reference.
"should considered similar to" would not bring any normative value for the scope of this document
I would suggest more information in the introductionary sections of this document to clearly state the main purpose of this document
| 2. **Assess Trust Status** | ||
|
|
||
|
|
||
| - Verify issuer is a trusted QTSP or recognized EAASP |
There was a problem hiding this comment.
or a PID Provider as well
| - Each member state may implement different registration approaches on top of the choice whether to use Registration Certificates or not | ||
|
|
||
|
|
||
| ## 5.2 Embedded Disclosure Policy Challenge |
There was a problem hiding this comment.
do we want an ETSI ref to the standard/specification defining the EAA embeeded policies?
|
|
||
| The wallet verifies whether the wallet-relying party complies with the requirements of the embedded disclosure policy and informs the wallet user of the result. | ||
|
|
||
| NOTE: The last option is based on the access certificate, not on the registration certificate. Since in the case of an intermediary, the access certificate identifies the RP |
There was a problem hiding this comment.
there might be some sort of mix of filters upon access certificates and WRPRC minimizing the attributes to be allowed in the presentation
|
|
||
| - The EUDIW must extract the actual RP identity from either: | ||
|
|
||
| - The Registration Certificate (linking RP to intermediary), or |
There was a problem hiding this comment.
I am wondering about the value of having an intermediary if I therefore have to store the logs and all the signed artifacts by myself, provide my access certificate and problably also my registration certificates
|
|
||
| **1. Access Certificate Issuance Infrastructure** | ||
|
|
||
| - Capability to issue Access Certificates to both: standard Relying Parties as Intermediaries acting on behalf of multiple RPs |
There was a problem hiding this comment.
in a proper scalable world, the federation authority would issuer the certificates to the RPI and this latter would issue and release the certificates, on its own, to its subordinates.
|
I have proposed the following PR with the purpose to describe many implementation scenarios: https://github.com/webuild-consortium/architecture/pull/31/files |
|
@WimCoulier It would be very much appreciated if you could go through the comments and reply to them. I think you might find the scenario overview created by @peppelinux to be interesting as well . |
Co-authored-by: Giuseppe De Marco <demarcog83@gmail.com>
3 participants
First draft of Intermediary testing proposal