Add Multi RP Credentials/Authentication capability #308
Conversation
There was a problem hiding this comment.
The JWS Compact Serialization is supported by essentially all implementations, whereas many don't support the JSON Serialization, in part, because JWTs don't use it.
I believe switching to the JSON Serialization would present an unnecessary burden to developers and harm interoperability.
(For what it's worth, I believe that adding the JSON Serialization a dozen or so years ago at all was a mistake, but I realize that that's water under the bridge.)
|
As I pointed out in the issue that this PR purports to resolve: when there is a trust infrastructure in place the request does not need to be signed as the wallet can determine the authenticity of the RP using the trust infrastructure. So we do not need multiple signatures and JSON serialisation. |
|
@David-Chadwick well... the wallet determines |
Co-authored-by: Stefan Charsley <charsleysa@gmail.com>
Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com>
Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com>
The profile supports unsigned requests. Would that be appropriate for your use cases? |
|
@Sakurann What you say is only one way of evaluating trust. The trust infrastructure can equally well decide if the RP is trustworthy or not based on its asserted name or ID. No keys are needed for this. If the asserted name/ID is deemed to be untrustworthy by the trust infrastructure, then the wallet knows not to trust the RP. If the name/ID is deemed to be trustworthy then there are two cases. 1. The RP is giving its true name, or 2. the RP is masquerading as a trustworthy RP. The latter can be protected against by the trust infrastructure providing the return URI of the RP for the wallet's response, and then the masquerading RP will not glean any information from the wallet. This is what we implemented. To prevent a DOS attack on the real trustworthy RP, we could add an extra protection feature, namely, the RP provides a random number on its request, which forms the query parameter on the wallet's reply to the return URI. The RP checks this parameter and if it is not recognised throws the wallet's response away. |
|
@tlodderstedt Yes, not requiring the RP's request to be signed solves the use case, and it also solves the problem of requiring multiple signatures to be on the request, because no signatures are actually needed. The RP can provide a set of names/IDs, one for each trust infrastructure that it is a member of. Then the wallet can match the presented trust infrastructures to the ones it is a member of, and where there is an intersection find out if the RP is trustworthy or not. |
@selfissued The requirement we are asked to fulfill is to allow for multiple RP credentials being proven (through signatures) in a single request. We have extensively discussed this requirement in the hybrid workshop and agreed to support it. The design in the PR is, in my opinion, the simplest and most robust solution we can do it (alternative proposals involved canonicalization). So from my standpoint, what we can do is to also continue to support compact serialization. That's why I asked that question further up. |
Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>
tlodderstedt
requested review from
martijnharing
and removed request for
charsleysa
| } | ||
| }, | ||
| "presentation_definition": {...} | ||
| "dcql_query": {...} |
There was a problem hiding this comment.
Why were the client_id, client_metadata, and jwks deleted? This change seems unrelated to the purpose of this PR.
There was a problem hiding this comment.
This is indeed related to this PR, as this data elements are RP specific. Consequently, the PR moves them into the RP credential specific elements of the request.
There was a problem hiding this comment.
We should discuss where the client_id, client_metadata, and jwks claims should go when using the Compact Serialization. These would normally be claims - not header parameters.
I understand the reasoning for making them header parameters when using the JSON Serialization, but in my view, that's not the normal case, and we should make the normal case natural.
| The signed Request Object MAY contain all the parameters listed in (#browser_api_request), except `request`. | ||
|
|
||
| Below is a non-normative example of such a request sent over the W3C Digital Credentials API: | ||
| The signed Request MUST use the JWS Serialization [@!RFC7515]). This allows the Verifier multiple Client Identifiers and corresponding key material and metadata when invoking a Wallet. This is to serve use cases where the Verifier requests credentials belonging to different trust frameworks and thus must authenticate in the context of those trust frameworks. |
There was a problem hiding this comment.
We should discuss whether to always use the JSON Serialization or only to use it when there are multiple signatures. (In this case, I realize that the "Keep simple things simple but make complex things possible" adage cuts both ways.) I'd rather keep the simple case simple.
There was a problem hiding this comment.
Thanks for your feedback (that's what I asked for in the description of the PR).
| The following request parameters MUST be present in the protected header of the respective signature object: | ||
|
|
||
| * `client_id` | ||
| * `client_metadata` |
There was a problem hiding this comment.
These aren't defined header parameters, so this is weird. Why aren't these being sent as claims in the request?
There was a problem hiding this comment.
because they are specific to a certain RP credential
| "payload": "eyAiaXNzIjogImh0dHBzOi8...NzY4Mzc4MzYiIF0gfQ", | ||
| "signatures": [ | ||
| { | ||
| "protected": "eyJhbGciOiJFUzI1NiJ9", |
There was a problem hiding this comment.
I would have expected a "kid" parameter - not just "alg".
There was a problem hiding this comment.
not sure what you mean, see an header example (with kid and alg) below
There was a problem hiding this comment.
eyJhbGciOiJFUzI1NiJ9 decodes to {"alg":"ES256"}, which has no kid.
Yes
No |
|
WG call: the sense of the "room" is we should not remove compact serialization. No support for adding multiple RP authentication feature to the HTTPS flow. |
This PR changes the way requests are signed to the Digital Credentials API from compact serialization (single RP) to JWS JSON Serialization (Multiple RPs).
Questions to the WG:
resolves #248