add option to have signed Credential Issuer metadata, remove signed_metadata from Credential Issuer metadata

[paulbastian]

Closes #202

• discuss whether to use JWS instead of JWT for multiple trust frameworks

[c2bo]

• discuss whether to use JWS instead of JWT for multiple trust frameworks

To give a bit more context on this: Paul and I had a bit of a discussion if we need to support multiple signatures similar to what was introduced in OpenID4VP. We came to the conclusion that starting with a JWT seems to be the more pragmatic choice and if we realise we need to support that feature, we could probably introduce it rather simple with a new media type (jose+json based).

Using JWT and different Issuer deployments for different trust ecosystems seems reasonable to me.

[sloops77]

Using the Accept header allows the wallet to indicate support for multiple content types as well. These changes clarify how that should be handled and shows a preference for signed metadata

[tplooker]

Discussed on the WG call, I would suggest we update the PR to clarify the following.

If the credential issuer supports metadata, it MUST support returning that in an unsigned form 'application/json' and MAY support returning it in a signed form 'application/jwt' which translates to if the accept header is absent or set to 'application/json' the credential issuer MUST always return JSON however when its set to 'application/jwt' it MAY instead return JSON if it doesn't support signed metadata.

[paulbastian]

I tried to permutate all possible configurations. There seem to be:

• 6 trivial options, that in my opinion don't need further explanation
• 2 options, that will not work anyway by policy
• 1 option, which I believe is what @sloops77 commented on

1. Wallet operates in a free ecosystem(Accept:json), Issuer operates in a free ecosystem(Content-Type:json) ✔️
2. Wallet operates in a free ecosystem(Accept:json), Issuer supports both(Content-Type:json) ✔️
3. Wallet operates in a free ecosystem(Accept:json), Issuer operates only in a trust framework ⛔
4. Wallet operates in both(Accept:json+jwt), Issuer operates in a free ecosystem(Content-Type:json) ✔️
5. Wallet operates in both(Accept:json+jwt), Issuer supports both ❓
6. Wallet operates in both(Accept:json+jwt), Issuer operates only in a trust framework(Content-Type:jwt) ✔️
7. Wallet operates only in trustframework(Accept:jwt), Issuer operates in a free ecosystem ⛔
8. Wallet operates only in trustframework(Accept:jwt), Issuer supports both(Content-Type:jwt) ✔️
9. Wallet operates only in trustframework(Accept:jwt), Issuer operates only in a trust framework(Content-Type:jwt) ✔️

In option 5, do we recommend signed_metadata or do we leave it up to the issuer? I would suggest leave it open in VCI, but no strong opinion

[paulbastian]

Another argumentation could be that previously support for signed_metadata was OPTIONAL, thus we could argue that support for unsigned metadata is REQUIRED by both Issuer and Wallet.

[paulbastian]

WG discussion:

• to not make a breaking change, we would need to make unsigned metadata support mandatory for Credential Issuers supporting metadata
• different implementations between Credential Issuer and AS, discussion around the motivation from deviating from RFC8414 -> security concerns about not having a complete signed metadata document
• please comment and review about Accept/content-Type approach vs RFC8414 approach

[charsleysa]

As I understand, one of the reasons behind this change is because of a concern that signed_metadata may not have all metadata included.

I think that would be easily solvable by mandating that all metadata (except signed_metadata) be present in the signed metadata and that wallets should use either the unsigned or the signed metadata and not mix the two.

If unsigned metadata support will be mandatory anyway, I don't see the need to have different methods of requesting signed metadata.

[UBaggeler]

I like the Accept/content-Type approach. In addition to the aforementioned arguments, as discussed in #528 (comment), this would allow for wallet apps and issuers to support multiple trust frameworks at the same time. E.g. using https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-jws-json-serialization as in OID4VP.

[markuskreusch]

I like the approach to decide based on Accept-Header about delivering signed or unsigned metadata more, than the mechanism described in RFC8414. It feels more natural to have the same resource available in different formats, instead of having the signed format embedded into the unsigned one. This way of doing it in RFC8414 seems odd. This together with the option to later add other formats or use multiple signatures, makes it the better option.

Concerning

5. Wallet operates in both(Accept:json+jwt), Issuer supports both ❓

I think this is not an issue. If the wallet really does not care, it can send the request accepting both formats and the issuer will decide. If it needs a specific format it can request only jwt or only json. Or it can request a jwt to get a jwt if possible and send another request with Accept:json if a 406 error has been received or use a quality factor, to specify the priority of the formats.

[sloops77]

I'm happy with the approach and concur that "Wallet operates in both(Accept:json+jwt), Issuer supports both" should not be defined in the spec

[c2bo]

Would HAIP then define how exactly the binding works for e.g., x5c?

[danielfett]

Looks good, left some comments.

[c2bo]

Agree with Daniel's suggestions and added a few more comments

[Sakurann]

wg discussion: good to merge once @c2bo and @leecam 's reviews are in.

[dastoikov]

Question: is there a way for a client requesting signed metadata to check if the server’s supported signing algorithms would match the former’s capabilities, and potentially negotiate preferences?

[jogu]

I think we wanted to keep it simple to start with (that's how the oauth signed metadata and federation work too I believe) - it is possible that we could define a future mechanism using a header or where the issuer returns a json serialised response with multiple signatures.

[dastoikov]

Thank you, @jogu!