SD-JWT VC requires iss value to be a URI

[awoie]

SD-JWT VC requires iss value to be a URI. HAIP currently does not require that, e.g., using DNS names.

[paulbastian]

HAIP currently says in Section 7: "https://openid.github.io/oid4vc-haip-sd-jwt-vc/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-wg-draft.html#section-7-5.3"

[paulbastian]

HAIP currently says: "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."
https://openid.github.io/oid4vc-haip-sd-jwt-vc/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-wg-draft.html#section-7.1-2.2

In fact, most x509 certificates SAN are DNS and therefore not a URI, so this is problematic

[awoie]

HAIP currently says: "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." https://openid.github.io/oid4vc-haip-sd-jwt-vc/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-wg-draft.html#section-7.1-2.2

In fact, most x509 certificates SAN are DNS and therefore not a URI, so this is problematic

We can fix either HAIP or SD-JWT VC:

• Either use dns:example.com for the iss value in HAIP, or
• we have to fix the language in SD-JWT VC to allow non-URI values to be used for iss AND define a rule to match the DNS SAN against the FQDN of the iss value. I'm not excited about allowing non-URIs for iss.

[OR13]

Allowing none URI values is probably more in keeping with JWT.

[paulbastian]

So my analysis is:

• we want Issuers to support both web-based and x509 keys at the same time
• almost all x509 certificates today use dNSName SAN
• SD-JWT VC disallows us this usecase as iss can only either be https:// or dns://
• I believe nobody has implemented iss with "dns://..."
• my proposal: always use HTTPS URL for iss, matchting rules for for certificate from x5c header is that
  • X509 Certificate with uniformResourceIdentifier SAN must match with iss
  • X509 Certificate with dNSName SAN must match the FQDN of the iss

[awoie]

So my analysis is:

• we want Issuers to support both web-based and x509 keys at the same time

• almost all x509 certificates today use dNSName SAN

• SD-JWT VC disallows us this usecase as iss can only either be https:// or dns://

• I believe nobody has implemented iss with "dns://..."

• my proposal: always use HTTPS URL for iss, matchting rules for for certificate from x5c header is that

  • X509 Certificate with uniformResourceIdentifier SAN must match with iss
  • X509 Certificate with dNSName SAN must match the FQDN of the iss

I'd be supportive of not using dns://. Can you propose this in the SD-JWT VC repository? I'm supportive of this direction.

[awoie]

Allowing none URI values is probably more in keeping with JWT.

@OR13 Yes, I'm not excited about relaxing the URI requirement but when I think about it, it might be useful since it would be easier to just match the iss value directly against the value in the SAN entry.

almost all x509 certificates today use dNSName SAN

Another thing I was interested in @paulbastian, which certificates are you referring to? Are you talking mostly about TLS certs? Are you concerned about that it would be not be easy for an issuer to obtain a cert with a SAN URI from an existing TLS CA? In that case, I was always wondering whether those usually issue certs with extended key usage "TLS server authentication" and whether that is set to Critical or Non-Critical, or if this was a decision that can be made in the CSR. If it was Critical, you won't be able to use those certificates, right?

Anyways, I'd rather have the discussion on changing SD-JWT VC in the SD-JWT VC repo for visibility reasons.

[awoie]

I believe this issue can be closed once this issue is closed: oauth-wg/oauth-sd-jwt-vc#232

[OR13]

Requirements should be relaxed in specifications, and strengthened in profiles... HAIP is for sure a profile, but it appears that sd-jwt-vc is also a profile, if haip depends on sd-jwt-vc I would expect haip to be more restrictive and sd-jwt-vc to be less restrictive.

[Sakurann]

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: I think see how some issuer devs might forget doing https://<DNS SAN> but at least in HAIP, the idea was for the issuer to support both key resolution mechanisms, so the chance of devs forgetting doing https:// is low, and the verifier supporting x509, would have to extract dns name from https:// 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.

[bc-pi]

update on SD-JWT VC where -04 has been published that includes this change sd-jwt vc 239 as resolution to this issue: oauth-wg/oauth-sd-jwt-vc#232

[babisRoutis]

update on SD-JWT VC where -04 has been published that includes this change sd-jwt vc 239 as resolution to this issue: oauth-wg/oauth-sd-jwt-vc#232

Given the above change in SD-JWT-VC, can the present issue be closed?