oid4vc-haip-sd-jwt-vc
oid4vc-haip-sd-jwt-vc copied to clipboard
openid
Issuers/Verifiers choice for either x5c or jwt-vc issuer metadata is not clear
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
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.
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.
Why should I do an HTTP call if the absence of kid can tell me that I shouldn't?
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?
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.
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.
as I said in https://github.com/openid/oid4vc-haip-sd-jwt-vc/issues/103#issuecomment-2129806601, 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.
