Support issuance and verification of IETF SD-JWT VCs without DID/X.509

[kristijantbtl]

Currently it doesn't seem possible to issue SD-JWT VC credentials which would then be verifiable (especially by 3rd-party implementations) in the manner described in section 5 of the relevant draft, where the iss claim is an HTTPS URL and the relevant public key is obtained via /.well-known/jwt-vc-issuer; i.e. the variation of public key resolution described in section 3.5 that does not involve X.509 certificates or DIDs.

The documentation only describes flows for issuing using X.509 or DID-based keys, so I assume this means there is currently no support for this?

Is your feature request related to a problem? Please describe.

The Issuer API's /jwks endpoint (referenced by URI in the response from /.well-known/jwt-vc-issuer) usually returns just {} instead of an actual JWK set, except for a small time period during the issuance protocol during which it seems to be populated before becoming {} again after (successful) completion of the flow. This prevents public key resolution using /.well-known/jwt-vc-issuer from working.

This issue also seems to persist regardless of any calls to /onboard/issuer prior to the flow (though I've only tested using JWK and without a KMS).

Describe the solution you'd like

Ideally, it would be possible to:

• make the Issuer API serve a proper JWK set on the /jwks endpoint beyond the end of the issuance flow;
• use it to issue SD-JWT VCs with the iss claim being a HTTPS URL, which would then be verifiable as described in the draft standard.

Describe alternatives you've considered

Using only X.509- or DID-based issuing, though these are far more involved to actually deploy, since they rely on existence of trust infrastructure or support for DIDs.

In comparison, JWT VC Issuer Metadata public key resolution approach is simpler for e.g. verifiers which only need to verify credentials of few or even just one known-in-advance issuer, as well as being more convenient for testing and development of such verifier implementations, and also being required for the OpenID4VC HAIP.

Additional context

Comments in the source code seem to suggest that this behavior of /jwks is due to some hacks regarding statefulness/statelessness of the Issuer API.

The response of /jwks is populated here.
Values are removed from the referenced collection here, which is called in the implementation of /token, thus making subsequent responses from /jwks after /token not include the public key used for signing this credential.

[alegomes]

Hello @kristijantbtl !

As it's been a while since your suggestion was made and several releases have been issued since then, could you please check if it still makes sense?

Thanks a lot.

Happy holidays!
Ale

[kristijantbtl]

Thanks for the reply!

Since the issue was posted, many things have happened.

We have upgraded to v0.9.0 and it seems this resolved the main issue with the Issuer's /jwks endpoint, in that the public keys used for issuing are now available on it after the issuing session is concluded. There are still some related issues which I've summarized below (thought I don't know whether any/all of these deserve their own GitHub issues).

We would still find it useful if JWT VC Issuer Metdata public key resolution were supported. Even if not supported in full, it would be nice to at least have an official way of setting the iss claim to the Issuer's HTTPS URI, as this seems required by standard even for X.509-based public key resolution (the SAN matching part).

We haven't looked into v0.10.0 yet, does it resolve any of the described issues?

---

A summary of outstanding issues, and what workarounds we've tried (as of v0.9.0):

• We haven't managed to find an easy way to set the value of the iss SD-JWT VC claim properly. According to the spec, this must always be a URI (which is then utilized in the appropriate way for public key resolution, which can vary), but from our experiments this doesn't seem to always be the case.

  • Note that even the X.509-based public key resolution variant also requires the iss to be HTTPS, not only the JWT VC Issuer Metadata variant this issue is about. If X.509 is officially supported, I assume there would be a way to set this correctly.
  • Currently, naive attempts to manually set the iss claim in the credential data in the payload to /openid4vc/sdjwt/issue to anything other than a DID (i.e. to the Issuer's HTTPS URI) have failed, as the value gets overriden.
  • There also doesn't seem to be a data function for the Issuer's HTTPS URI, but there is one for a DID.
  • It seems that (when not given a DID, at least) the Issuer chooses a random base64-looking string to set as the iss (which obviously won't be a URI as required by spec), and that it also adds this same string as the kid of the corresponding public key served on /jwks. Through some fiddling, we've discovered that manually setting the kid in the private JWK passed in the call to /openid4vc/sdjwt/issue to some value causes the Issuer to copy this value into the iss claim of the credential. While this doesn't seem to be documented (is this intentional?), so far we've resorted to using this as a workaround for setting the iss claim to the Issuer's HTTPS URI, thus enabling us to get a step further.

• When attempting to present SD-JWT VCs with an HTTPS URI iss to the Verifier, we encountered the following error:

  (...)
  Caused by: java.lang.IllegalArgumentException: Verification policies did not succeed: signature_sd-jwt-vc ("java.lang.UnsupportedOperationException: Resolving issuer key from SD-JWT is only supported for issuer did in kid header and PEM cert in x5c header parameter
  

  which seems to indicate that this is indeed not yet considered all-around supported, despite /jwks being implemented.

• When the same private JWK is used repeatedly to issue credentials, its public key will be listed repeatedly in the /jwks JWK Set. This doesn't seem completely right w.r.t to the JWK Set spec, as it states that the kid values should be distinct within a JWK Set, which they won't be due to the duplicates.

  • This is not that big of a deal as long as the key is in fact identical, as this wouldn't lead to signature verification failures. However, in conjunction with the kid-based iss-setting workaround described above, this effectively limited the number of distinct keys the Issuer can safely use to 1, as different keys should not have the same kid (and we resorted to using kid to set iss to always the same HTTPS URI where the Issuer is reachable).

---

Thank you for your time!