I was working to implement JWK thumbprint as a possible subject_syntax_type for Self Issued ID Token. Especially when used in combination with vp_token and SD-JWT VCs that are bound to JWKs it's beneficial to not have to use a did (although you can convert the jwk to e.g. a did:key or did:jwk, it's nicer to not have to do this).
However after doing some refactorings, I ran into that issue that this library heavily depends on did-jwt, which as the name suggests focuses on JWTs signed by dids.
What would be the best way forward around this? Not leveraging did-jwt for JWTs not signed by dids is possible, but it would require a lot of code then that could also be used for did-jwt.
I'm not sure if did-jwt could support other mechanisms than dids, but looking at the package name, I'd assume it's out of scope.
Another possbility would be to make the suppiled signature more complex to configure and allow to plug in your own jwt implementation. e.g. in AFJ we have our own JWS / JWT implementation, so we could manually sign the whole JWT payload if we get the input payload and headers. Then this library by default would only support did signing, and if you want JWK signing you need to pass in something yourself.
I was working to implement JWK thumbprint as a possible subject_syntax_type for Self Issued ID Token. Especially when used in combination with vp_token and SD-JWT VCs that are bound to JWKs it's beneficial to not have to use a did (although you can convert the jwk to e.g. a did:key or did:jwk, it's nicer to not have to do this).
However after doing some refactorings, I ran into that issue that this library heavily depends on did-jwt, which as the name suggests focuses on JWTs signed by dids.
What would be the best way forward around this? Not leveraging did-jwt for JWTs not signed by dids is possible, but it would require a lot of code then that could also be used for did-jwt.
I'm not sure if did-jwt could support other mechanisms than dids, but looking at the package name, I'd assume it's out of scope.
Another possbility would be to make the suppiled signature more complex to configure and allow to plug in your own jwt implementation. e.g. in AFJ we have our own JWS / JWT implementation, so we could manually sign the whole JWT payload if we get the input payload and headers. Then this library by default would only support did signing, and if you want JWK signing you need to pass in something yourself.
Related to https://github.com/Sphereon-Opensource/SIOP-OID4VP/issues/55