Constraints on using JWT VC Isser metadata and x5c

[paulbastian]

The text currently says:

JWT VC Issuer Metadata: If a recipient supports JWT VC Issuer Metadata and if the iss value contains an HTTPS URI, the recipient MUST obtain the public key using JWT VC Issuer Metadata as defined in Section 5.

X.509 Certificates: If the recipient supports X.509 Certificates, the recipient MUST obtain the public key from the leaf X.509 certificate defined by the x5c JWT header parameters of the Issuer-signed JWT and validate the X.509 certificate chain in the following cases: [...]

It must by the Issuer's choice to support either x5c, jwt-vc metadata or both, this is also how HAIP defines it. Extending this thought, the Verifier has no means of understanding what the issuer supports, given that iss may be an HTTPS URI but no support is avaiblable for jwt-vc metadata. This is because kid is the best indicator but in Section 5 only described as RECOMMENDED.

Proposal is that the Issuer may chose this and that the presence of kid in SD-JWT VC indicates jwt-vc metadata.

[awoie]

This is from HAIP:

This profile supports two ways to represent and resolve the key required to validate the issuer signature of an SD-JWT VC, the web PKI-based key resolution and the x.509 certificates.
Web-based key resolution: The key used to validate the Issuer's signature on the SD-JWT VC MUST be obtained from the SD-JWT VC issuer's metadata 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.
x.509 certificates: the SD-JWT VC contains the issuer's certificate along with a trust chain in the x5c JOSE header. In this case, the iss value MUST be an URL with a FQDN matching a dNSName Subject Alternative Name (SAN) [RFC5280] entry in the leaf certificate.
Note: The issuer MAY decide to support both options. In which case, it is at the discretion of the Wallet and the Verifier which key to use for the issuer signature validation.

By following the HAIP text, I don't understand how an issuer can support both options in an SD-JWT VC? Can you give an example?

Furthermore, DNS name is not a URI and strictly speaking is this not allowed as per SD-JWT VC where iss has to be a URI. For that reason, SD-JWT VC says that the iss value needs to be encoded using the dns URI scheme.

I'm not saying SD-JWT VC should not be changed in that regards because I do see some potential for improvement and I think as well that an issuer might want to support both and that needs to be addressed. We should discuss ways how this can be achieved.

But I don't think kid is appropriate for this to control whether a verifier fetches well-known or not. I would assume that a verifier will likely know which issuer (iss value) to trust and also know if the issuer is part of some trust framework that supports well-known. If not, the verifier will have to try in the same way as they try other well-knowns. I don't see the need to connect the presence of kid with the presence of well-known if this is what you suggested.

Furthermore, I believe your specific use cases is already supported by:

1. using an HTTPS URI for the iss value
2. hosting a well-known for that URI
3. including a x5c header with a URI SAN entry that matches the iss value

[awoie]

I don't think using kid to indicate whether well-known is supported is a good solution. I don't think we need this indication for the reasons pointed out above.

(we can discuss whether dns URI scheme is a good solution in general but this is a separate topic and whether we should not limit iss to be a URI)

[peppelinux]

@awoie at least for using kid with openid federation is resonable, because that kid is resolved within a federation trust chain

[awoie]

@awoie at least for using kid with openid federation is resonable, because that kid is resolved within a federation trust chain

I think there is nothing wrong with:

1. using an HTTPS URI for the iss value
2. hosting a well-known for that URI
3. including a x5c header with a URI SAN entry that matches the iss value
4. adding kid to the header

In that case, using the kid to indicate whether well-known is supported or not would not work because like @peppelinux mentioned, apparently OpenID federation uses kid as well and I believe in that case, well-known is not required. Please correct me if I'm wrong.

@peppelinux Can you explain how OpenID federation resolves the kid?

[awoie]

@awoie at least for using kid with openid federation is resonable, because that kid is resolved within a federation trust chain

I think there is nothing wrong with:

1. using an HTTPS URI for the iss value
2. hosting a well-known for that URI
3. including a x5c header with a URI SAN entry that matches the iss value
4. adding kid to the header

To be clear, the above is valid.

In that case, using the kid to indicate whether well-known is supported or not would not work because like @peppelinux mentioned, apparently OpenID federation uses kid as well and I believe in that case, well-known is not required. Please correct me if I'm wrong.

To be clear, the above just means that using kid to control how the verifier has to resolve the key does not work because people using OpenID federation might not host a well-known endpoint but will also need a kid.

[peppelinux]

@awoie sure, thank you for asking

imagine the federation trust chain like an object, related to a subject (giuseppe, a trustable entity) linked to a trust anchor (a trusted party over all the others), wwhere in the middle we may have zero, one or more intermediaries between the subject (leaf) and trust anchor.

the leaf's metadata can be overloaded by the statements within the chain, along the trust anchor. Therefore the jwks the leafs claims to use, and any other protocol specific metadata, can be dynamically overloaded within the trust chain, by applying the metadata policies.

once the policies are applied, the resulting metadata is called final metadata and contains all the jwks related to an entity, for each protocol (since a federation entity configuration may have more than a single metadata creafted for a speicifc role, such as VCI, RP, OP and so on).

using the final metadata, the kid is needed in the form of lookup parameter within the JWKs provided within the final metadata

[peppelinux]

the resolution of the kid is interesting

we may have a discovery, using well known endpoints
we may have a static trust chain, provided like a x.509 certificate chain

[awoie]

@awoie at least for using kid with openid federation is resonable, because that kid is resolved within a federation trust chain

I think there is nothing wrong with:

1. using an HTTPS URI for the iss value
2. hosting a well-known for that URI
3. including a x5c header with a URI SAN entry that matches the iss value
4. adding kid to the header

To be clear, the above is valid.

In that case, using the kid to indicate whether well-known is supported or not would not work because like @peppelinux mentioned, apparently OpenID federation uses kid as well and I believe in that case, well-known is not required. Please correct me if I'm wrong.

To be clear, the above just means that using kid to control how the verifier has to resolve the key does not work because people using OpenID federation might not host a well-known endpoint but will also need a kid.

@paulbastian To be even more clear, they might not host a SD-JWT VC Issuer Metadata well-known endpoint but they might host an OpenID Federation well-known endpoint.

[awoie]

@awoie sure, thank you for asking

imagine the federation trust chain like an object, related to a subject (giuseppe, a trustable entity) linked to a trust anchor (a trusted party over all the others), wwhere in the middle we may have zero, one or more intermediaries between the subject (leaf) and trust anchor.

the leaf's metadata can be overloaded by the statements within the chain, along the trust anchor. Therefore the jwks the leafs claims to use, and any other protocol specific metadata, can be dynamically overloaded within the trust chain, by applying the metadata policies.

once the policies are applied, the resulting metadata is called final metadata and contains all the jwks related to an entity, for each protocol (since a federation entity configuration may have more than a single metadata creafted for a speicifc role, such as VCI, RP, OP and so on).

using the final metadata, the kid is needed in the form of lookup parameter within the JWKs provided within the final metadata

Thank you for this elaboration! It means that in this case, you won't need SD-JWT VC Issuer Metadata well-known, right?

[peppelinux]

Thank you for this elaboration! It means that in this case, you won't need SD-JWT VC Issuer Metadata well-known, right?

using federation the metadata must be signed and evaluated within the trust chain, therefore, yes, there are no direct dependencies with the SD-JWT VC Issuer Metadata well-known endpoint, even if these two can cohexist within the same entity.

[awoie]

I'm supportive of changing iss value requirements for the following reasons:

• using dns:// could be a bit misleading
• using https://example.com to match against the SAN DNS value is error prone (some devs might forget to do FQDN(iss) == SAN DNS value and instead do iss == SAN DNS value) and
• perhaps misleading if https://example.com does not exist (although the domain exists). Perhaps an edge case but it might have security implications.

[Sakurann]

I'm supportive of changing iss value requirements

to chage the iss requirement to be not a URI but a string for cases when iss is a DNS SAN value?

the point of https://<DNS SAN> in HAIP was that the issuer can use the same iss value in sd-jwt vc to support various key resolution mechanisms - web-based key resolution (.well-known/jwt_vc_issuer with or without openid federation) or x509. so I am supportive of keeping iss a URI in sd-jwt vc, but change the scheme to https: as opposed to dns: regarding your points 2 and 3, for example, in HAIP, the idea was for the issuer to support both key resolution mechanisms, so the chance of devs forgetting doing https://<dns name> is low, and the verifier supporting x509, would have to extract dns name from https://<dns name> as part of validations steps, so I see your points, but still think the the benefits of the same iss with different key resolution mechanisms is strong.

[paulbastian]

I support this, see my reasoning here:
openid/OpenID4VC-HAIP#103 (comment)

[bc-pi]

@awoie and I chatted briefly and are leaning towards keeping the requirement on iss to be a URI while using an https scheme for both key resolution mechanisms.