Vincent Prouillet
Vincent Prouillet
See https://github.com/Keats/tera/issues/637#issuecomment-1891976443 as well. That would be in Tera but not coming anytime soon
Can we have another enum containing https://github.com/jblachly/jsonwebtoken/commit/79774926a9c58c442cd2fe433cc032d0eecb3f22#diff-9f82b0117510d782b99dcd289413911ac2a437265e598c9562877ad9613736d8R50-R101 and have 2 types for JWK: one supported and one unsupported? So at least the deserialization works but you don't get the impression...
> What is benefit of those keys in JWK Set when we don't have encoding/decoding capabilities yet? Just so it doesn't error out like when deserializing like in your issue...
Me neither. If we use a different enum than `Algorithm` and add a `JWK.is_supported` or something it would be ok I think.
It's just not self-documenting. The `Algorithm` enum is there to list all the _supported_ algorithms. Adding a catch-all that is in fact invalid later goes against that principle.
Anyone interested in writing the PR?
That should be fixed
Isn't that what `time` does already? https://github.com/time-rs/time/blob/916004f5e3aef2f249d57ba828550be55ed7aaf3/time/src/date_time.rs#L307 Granted you can skip `time` entirely and just have the function in jsonwebtoken to avoid a dependency.
We have wasm tests in CI now and it seems to pass?
We do run tests in wasm (https://github.com/Keats/jsonwebtoken/blob/master/.github/workflows/ci.yml#L63). Other than that i don't know what else is missing