-
Notifications
You must be signed in to change notification settings - Fork 376
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
JWK Parameters #518
Comments
Hi, great to hear from you again :) You're right, the JWK implementation is pretty much based on the JWT needs currently. Pretty soon after implementing the support it started to feel that the JWK parts deserved it's own library, also now knowing a lot more about the context the solution would probably look a lot different :) About using the What about usage being something like
Also when reading a JWK the values not directly supported by the internals could be stored in the same place these Even better would probably be a implementation that would support the specific attributes a JWK is supposed to support, otherwise changing behaviour to a more specific way later will be impossible without breaking the API. |
Also the key accessor feels like a natural way to access JWK attributes. 👍 for that. Not sure if mutating the JWK via those is going to be confusing if you cannot change everything via that, what would happen if one would do |
Hey @anakinj, also nice to hear from you again :)
I guess collecting all additional attributes under a key
Great idea 👍
I have not looked much into the history of this gem, but options like
As a user, I would expect JWK to behave like a "hash with benefits".
Of course, there are loads of optimizations here.
Note however that it may not be possible to construct a valid internal representation at all after a single change. So maybe this isn't a solution after all. Alternatively one could allow programmers to access the saved |
Good points. Are you interested in taking a shot on implementing something like this? Also open for pairing if you're into that :) Maybe starting with the |
I can send a PR your way probably on monday and mark you for a review. Maybe this is a helpful starting point for further discussions :) |
Lovely. Looking forward for that. |
Hey there :)
I was trying to use this gem, and the JWK implementation in particular, to handle any kind of cryptographic material for which I would normally go with several files in a format like PEM. This includes public and private key pairs, as well as certificates.
In principle, the JWK specs are built to handle all this kind of stuff, as can be seen e.g. in the IANA registry.
Note in particular the
x5*
claims for certificates.It would be nice if there were some option to include these parameters in
JWT::JWK
and have it be exported alongside the actual key values. Currently this is not the case, because most values (excludingkid
andkty
) are stored internally in an OpenSSL-compatible format (which is a good thing, I think, since cryptographic operations are often a lot more time-critical than serialization).I do recognize that supporting the full set of semantics connected to these additional parameters may be a massive increase in scope for this project (e.g. any certificates in
x5c
must be signed by the next one in the array (let's not start talking about conformance to all X.509v3 extensions limiting who can sign what) with the first certificate referencing the very key in the JWK, and theuse
parameter should probably also be checked at some point or another).A much more reasonable approach, if properly documented, would be to just allow people to add custom properties to the JWK. This is in a way similar to how this gem supports adding arbitrary claims to a JWT, but only actively provides guidance and validation for some of them (e.g.
iss
,aud
, etc.).The way I would envision this is by using the
options
argument in KeyBase and just saving it after removingkey_generator
(note thatkid
is actually one of the custom parameters, and can be saved among them :) ).When the JWK is later exported, any keys in the saved
options
are merged into the result.One step up from this would be a method to access and manipulate these
options
(maybe even as usability-friendlymy_jwk['use']
).I would be happy to hear some feedback on this idea and whether this endeavor and whether it may be beneficial to the project.
The text was updated successfully, but these errors were encountered: