Add Multi RP Credentials/Authentication capability

[tlodderstedt]

This PR changes the way requests are signed to the Browser 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 Browser API profile?
• Do we want the Multi RP capability to the traditional OID4VP flow?

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