Issuers/Verifiers choice for either x5c or jwt-vc issuer metadata is not clear

[paulbastian]

It is not clear whether the Issuer or the Verifier has the choice for the two key management options. Clearly define who's choice it is

[awoie]

SD-JWT VC currently says, if iss value is a HTTPS URI, do JWT Issuer Metadata, if it is not, then look at the x5c header and try to match one of the SAN values against the iss value.

Ecosystems can add additional rules as per SD-JWT VC.

[OR13]

In SCITT, we did something similar. When x5t is present, check for x5c (could be in unprotected header in cose). We did not require a specific SAN to match the iss field, as of the latest draft.

When only iss is present, somehow figure out how to get to a key, and if that key contains a chain, optionally verify the chain as well... x5c can show up in JWK, but does not show up in COSE Key.

[paulbastian]

Why should I do an HTTP call if the absence of kid can tell me that I shouldn't?

[OR13]

Are you saying either kid is present or x5t is present?

[awoie]

Why should I do an HTTP call if the absence of kid can tell me that I shouldn't?

If there is a x5c header, why would you do an HTTP call?

[henkbirkholz]

When x5t is present, check for x5c (could be in unprotected header in cose)

If there is a x5c header, why would you do an HTTP call?

The x5c could have been tempered with.

[awoie]

When x5t is present, check for x5c (could be in unprotected header in cose)

If there is a x5c header, why would you do an HTTP call?

The x5c could have been tempered with.

For JWTs compact, this is not the case because there are only protected headers, for JWTs JSON serialization, you could still put the x5c in the protected header, or put the x5t in the protected which secures the x5c.

[Sakurann]

as I said in #103 (comment), the intention of HAIP was that the issuer has to issue using two key resolution mechanisms - web-based key resolution (.well-known/jwt_vc_issuer with or without openid federation) or x509, and the verifier has to support only one of those. (which is also why the intention was to be able to use the same iss value for both key resolution mechanisms.

[tlodderstedt]

please also move the following bullet from "OpenID for Verifiable Presentations profile for IETF SD-JWT VC" to "# SD-JWT VCs {#sd-jwt-vc}" section:

* To obtain the Issuer's public key for Verification, Verifiers MUST support Web-based key resolution, as defined in Section 5 of [@!I-D.ietf-oauth-sd-jwt-vc]. The JOSE header kid MUST be used to identify the respective key.

[jogu]

#178 (if merged) would I believe resolve this issue (by removing web based key resolution).