Add Multi RP Credentials/Authentication capability

[tlodderstedt]

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:

• Do you want to keep (re-add) the JWS Compact Serialization to the Digital Credentials API profile?
• Do we want the Multi RP capability to the traditional OID4VP flow?

resolves #248

[selfissued]

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.)

[David-Chadwick]

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.

[Sakurann]

@David-Chadwick well... the wallet determines the authenticity of the RP using the trust infrastructure based on the keys used to sign the request, that's why signature is crucial here.

[tlodderstedt]

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.

The profile supports unsigned requests. Would that be appropriate for your use cases?

[David-Chadwick]

@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.

[David-Chadwick]

@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.

[tlodderstedt]

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.)

@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.

[selfissued]

Why were the client_id, client_metadata, and jwks deleted? This change seems unrelated to the purpose of this PR.

[tlodderstedt]

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.

[selfissued]

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.

[tlodderstedt]

client_id, client_metadata, and jwks are request parameters when using the Compact Serialization. see examples/digital_credentials_api/signed_request_payload_compact.json

[selfissued]

These aren't defined header parameters, so this is weird. Why aren't these being sent as claims in the request?

[tlodderstedt]

because they are specific to a certain RP credential

[selfissued]

I would have expected a "kid" parameter - not just "alg".

[tlodderstedt]

not sure what you mean, see an header example (with kid and alg) below

[selfissued]

eyJhbGciOiJFUzI1NiJ9 decodes to {"alg":"ES256"}, which has no kid.

[bc-pi]

Do you want to keep (re-add) the JWS Compact Serialization to the Digital Credentials API profile?

Yes

Do we want the Multi RP capability to the traditional OID4VP flow?

No

[tlodderstedt]

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.

[bc-pi]

wouldn't this be problematic or at least awkward for parameters like the trust chain thing from openid federation that are specific to the trust framework of the given client id?