Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Best way to support JWK thumbprint as subject_syntax_type? #154

Open
TimoGlastra opened this issue Jan 25, 2024 · 0 comments
Open

Best way to support JWK thumbprint as subject_syntax_type? #154

TimoGlastra opened this issue Jan 25, 2024 · 0 comments

Comments

@TimoGlastra
Copy link
Collaborator

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 Sphereon-Opensource/SIOP-OID4VP#55

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant