search

openid / oid4vc-haip-sd-jwt-vc

High Assurance Profile of OID4VP and OID4VCI using SD-JWT VC and mdocs that is privacy preserving, secure, and meets regulatory requirements
29 stars 7 forks source link

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

Open paulbastian opened 6 months ago

paulbastian commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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

OR13 commented 6 months ago

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

awoie commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 5 months ago

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.