Open sidrubs opened 6 days ago
There's https://github.com/Keats/jsonwebtoken/pull/402 which is the start of the same idea minus traits. The idea was to support aws-lc-rs and rust-crypto. I didn't consider traits but i guess it would work fine.
Aah ok I see how #402 is being done.
If one were to extend that to use traits, and expose the trait API in addition to the current encode
and decode
functions, it would allow an escape hatch for people to provide whichever crypto their use-case requires.
Should I write up a PR incorporating ring
, aws-lc-rs
, and RustCrypto
using a traits implementation?
I don't want to step on anyone's toes or mess with PRs currently in progress. So if you feel the traits route isn't the correct direction, I'm fine with maintaining a fork for my use-case.
https://github.com/Keats/jsonwebtoken/pull/318 has been merged on the next branch as well.
As for doing the PR, you can see with @GlenDC what he prefers
Hi,
I see there has already been a bit of activity surrounding crypto backend support. We have a use-case where we would like to provide an arbitrary "signer" and "verifier" (e.g. a call out to an HSM). I would, personally, prefer to get this into the
jsonwebtoken
crate, rather than maintaining a fork, as I don't like unnecessary fragmentation of the ecosystem.I am more than happy to make the PR (making sure that we don't break backwards compatibility). Is this something that the
jsonwebtoken
crate would consider including?I did a very rough POC making use of RustCrypto's
signature::Signer
andsignature::Verifier
traits.Setting up signing and verifying traits:
Performing the encoding:
One could implement default signing and verifying modules using
ring
(or RustCrypto, oraws-lc-rs
) and could put all the "complexity" of the creating the signing and verifying modules behind the current public facingencode
anddecode
functions so that this does not introduce breaking changes.Is there anything else I would need to consider?