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