Closed psilospore closed 2 months ago
yak on the FP discord approach suggested this:
I was going to point you to what i think is the library's intended approach to this problem as is shown in its haddock examples in Crypto.JOSE.JWK.Store
....which look for the appropriate JWK/s based on kid param and/or the iss claim like you mentioned you wanted to do.
once you have the appropriate VerificationKeyStore instance set up to grab the correct JWK/s, you should be able to easily track how: that class's getVerificationKeys method gets used in verifyJWSWithPayload (in Crypto.JOSE.JWS); and that, in turn, gets used in verifyJWT/verifyClaims (in Crypto.JWT)
(edit: if i’m reading it right, things should just work once you include into your function’s class constraints whatever newtype wound up taking the place in your own problem case to those shown in the linked haddock examples for the VerificationKeyStore instances)
Yes, the way to do this is via a custom key store implementation.
If you find any shortcomings or could suggest documentation improvements (or want to contribute your key store implementation as an example), please reach out.
Thanks! (closing this now)
Hi I have certain use cases where I would like to access to fields from
SignedJWT
. I could be wrong but it seems that the current api seems to restrict access to fields in that type expecting a caller to first callverifyClaim
/verifyJWS
.Here's the two use cases where I have where this doesn't seem to work for us:
JWKSet
for the associated issuerMy workaround is to just
toJSON signedJWT
and then base64 decode the header and payload. However it would be nice if I could access it from that type.