Public key resolution

[mat-work]

RFC001, RFC002, RFC003, and RFC005 include an appendix related to public key resolution.

For SD-JWT, it would be beneficial to clarify the case of signing credentials using X.509 certificates.

As per the SD-JWT specification, the public key should be extracted from the certificate chain present in the x5c header of the Issuer-signed JWT. This includes validating the X.509 certificate chain and ensuring the iss value matches the SAN entry in the end-entity certificate.

Please refer to the full specifications for additional context.

X.509 Certificates: If the recipient supports X.509 Certificates and the iss value contains an HTTPS URI, the recipient MUST

• obtain the public key from the end-entity certificate of the certificates from the x5c header parameter of the Issuer-signed JWT and validate the X.509 certificate chain accordingly, and
• ensure that the iss value matches a uniformResourceIdentifier SAN entry of the end-entity certificate or that the domain name in the iss value matches the dNSName SAN entry of the end-entity certificate.`

[lalc]

I am happy to update RFC001 to reflect this, and we can release it for v2.2. Any objections? @andreasabr @endimion @ntsbs @ed-curran @georgepadayatti

[ed-curran]

I am happy to update RFC001 to reflect this, and we can release it for v2.2. Any objections? @andreasabr @endimion @ntsbs @ed-curran @georgepadayatti

We support x5c for sd-jwt vc like this already, so good for me.

[endimion]

I am good as well... already implemented this as part of the ITB.. so if everyone is happy let me know when to do that...

[andreasabr]

no objections from my side, go ahead @lalc

[pcosio]

After a short discussion with @endimion , I decided to write down my doubts regarding public key resolution and how it is implemented in the EWC conformance issuer (https://dss.aegean.gr/rfc-issuer/). This comment is very long... so you can go directly to the summary that it's at the end of this comment.

In the RFC001, link to the HAIP should be updated to:
https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0.html
Regarding the sd-jwt vc IETF, HAIP points to:

• ietf sd-jwt draft version 08: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-08
• oid4vci draft 14: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html

Should that be well specified in the RFC001? I will create a pull request for suggesting that and clarifying this point: https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/ewc-rfc001-issue-verifiable-credential.md#appendix-a-public-key-resolution

But firstly, let's check what says HAIP and IETF regarding public key resolution and why the EWC conformance issuer should include kid (or x5c) claim in sd-jwt:

• HAIP. The iss claim MUST be an HTTPS URL. The iss value is used to obtain Issuer's signing key as defined in Section 7.1.
  Section 7.1. Issuer identification and key resolution to validate an issued Credential:

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.

Current sd-jwt signed by the EWC conformance issuer is signed by using the first way. Let's see it using an example:

eyJ0eXAiOiJ2YytzZC1qd3QiLCJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJodHRwczovL2Rzcy5hZWdlYW4uZ3IvcmZjLWlzc3VlciIsImlhdCI6MTczNDAyMjE1MiwidmN0IjoiVmVyaWZpYWJsZVBvcnRhYmxlRG9jdW1lbnRBMVNESldUIiwiaWQiOiJlN2EzMjFhYS01YjNiLTRlMmQtOGMzNS03ZTQ3NTgyMzFkNTMiLCJjbmYiOnsiandrIjp7Imt0eSI6IkVDIiwieCI6IlFEMXRoUzQteW1jWmVjRUF1Q19lUGZBcWNYTXd4THU3LUIydW9POVduU0EiLCJ5IjoicDdNTVQ1c2s2RGg3SU1aMVlzMVdRa2hCYk41R2pIbzBPbVhjWXlUVmJOOCIsImNydiI6IlAtMjU2In19LCJfc2QiOlsiMWI2Vlh2cWRVakZuNG5MN0J0WkpTeEJaMlFpNXpwT3dzdnRTdTV5eDBUdyIsImI2RnVpWVlUQXdZNDBkQkFhdzJDWXVHbno5bWIzWjNmQkRrVGlLYko4RDgiXSwiX3NkX2FsZyI6InNoYS0yNTYifQ.MN18ic7jeQvl7JD_n7qoMITSA_o2pGoXi2LfDLWU-nVu_kF8Qba5y00ISOyuck6Up9E843oTn7G3Vu4QhTOjIQ~WyI0Y2I2OWVkYjcxOTYwNTAxIiwibGFzdF9uYW1lIiwiRG9lIl0~WyJkNDg3YTVlOTUzNmVkNTliIiwiZ2l2ZW5fbmFtZSIsIkpvaG4iXQ

sd-jwt decoded:

• header

{
  "typ": "vc+sd-jwt",
  "alg": "ES256"
}

• Body

{
  "iss": "https://dss.aegean.gr/rfc-issuer",
  "iat": 1734022152,
  "vct": "VerifiablePortableDocumentA1SDJWT",
  "id": "e7a321aa-5b3b-4e2d-8c35-7e4758231d53",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "x": "QD1thS4-ymcZecEAuC_ePfAqcXMwxLu7-B2uoO9WnSA",
      "y": "p7MMT5sk6Dh7IMZ1Ys1WQkhBbN5GjHo0OmXcYyTVbN8",
      "crv": "P-256"
    }
  },
  "_sd": [
    "1b6VXvqdUjFn4nL7BtZJSxBZ2Qi5zpOwsvtSu5yx0Tw",
    "b6FuiYYTAwY40dBAaw2CYuGnz9mb3Z3fBDkTiKbJ8D8"
  ],
  "_sd_alg": "sha-256"
}

According to the HAIP, what it is missing here is the kid claim into the header that should contain the value aegean#authentication-key

Other issue is how to perform the web key resolution so that the verifier can verify the issuer's signature. Just now, the process is:

• Get the issuer url. In this case: https://dss.aegean.gr/rfc-issuer
• Go to the issuer metadata: https://dss.aegean.gr/rfc-issuer/.well-known/openid-credential-issuer
• Get the auth server from there, and go to the auth server metadata: https://dss.aegean.gr/rfc-issuer/.well-known/oauth-authorization-server
• Get the jwks_uri and go there: https://dss.aegean.gr/rfc-issuer/jwks
• Now, the verifier can get the key that corresponds to the key identifier (kid) defined in the sd-jwt header. Then, the verifier can perform the issuer's signature validation

Well, according to the IETF, the way for the verifier to resolve the key is defined here:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-08#name-issuer-signed-jwt-verificat
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.

Section 5. JWT VC Issuer Metadata
Issuers publishing JWT VC Issuer Metadata MUST make a JWT VC Issuer Metadata configuration available at the location formed by inserting the well-known string /.well-known/jwt-vc-issuer
It means that the issuer metadata whould be published at https://dss.aegean.gr/rfc-issuer/.well-known/jwt-vc-issuer

The issuer could express the key using certificates. In fact it's the title of the discussion/issue started by @mat-work. For that the EWC conformance issuer should make some changes:

• According to the HAIP and IETF: x5c claim must be in the sd-jwt header with the certificate chain. Example:

x5c: [
    'MIIDqjCCApKgAwIBAgIESLNEvDA ...',
    'MIICwzCCAasCCQCKVy9eKjvi+jA ...',
    'MIIDTDCCAjSgAwIBAgIJAPlnQYH...'
  ],

• iss claim in the sd-jwt payload should be the same than the dNSName that is in the final certificate

SUMMARY

• kid claim is missing in the header. It is already specified in the RFC (https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/ewc-rfc001-issue-verifiable-credential.md#appendix-a-public-key-resolution)
• IETF defines that the issuer metadata should be at /.well-known/jwt-vc-issuer. It's not specified in the RFC
  These last two points should be implemented in the EWC conformance issuer if we want to be compatible with HAIP
• jwks response (https://dss.aegean.gr/rfc-issuer/jwks) should have different kid for each key.

[lalc]

@mat-work @georgepadayatti @endimion Could you please check and comment above by @pcosio?

[endimion]

Hey all,

I mostly agree with Pablo, so bulletts 1 and 3 have been resolved now. With respect with bullet 2, and how to perform the web key resolution ... do I understnad correctly that this " /.well-known/jwt-vc-issuer" comes from HAIP in combination with OIDC4VCI v14? Because in the current RFCs we support v13 maybe this is what is causing the issu? Of course exposing the keys under a different endpoint is not a big deal but we need to clarify this to ensure interoperability

[pcosio]

thanks for the response @endimion .

I agree with you about bullet 2 ("/.well-known/jwt-vc-issuer"). I think it comes directly from IETF sd-jwt vc, but both OID4VCI draft 13 and draft 14 defines it as "/.well-known/openid-credential-issuer". So, probably we should not take it into account. I've checked that HAIP does not say anything about the path of the credential issuer metadata

[endimion]

awesome, so all issues resolved for now? If so can we close this?

[pcosio]

Hi @endimion
from my side the issues are solved
Looking at the HAIP, regarding the public key resolution for being able to verify the issuer's signature:
https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0-00.html#name-issuer-identification-and-k
Just now, we are following the approach "Web-based key resolution", so the EWC conformance issuer is not using the x.509 approach.

The only non-compliance issue that I see with regards to the HAIP is the url where is published the issuer metadata. HAIP points that to the IETF (draft 01) and it's defined there that it must be "/.well-known/jwt-issuer". But now, I am not sure how it should be managed. Maybe, the way how public key resolution is currently done (web-based key resolution with metadata url paths defined in OID4VCI) could be specified here?
https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/ewc-rfc001-issue-verifiable-credential.md#appendix-a-public-key-resolution

What do you think?