Method for generating basic JWS protected header from JWK instance

Question

Method for generating basic JWS protected header from JWK instance

EternalDeiwos opened this issue 7 years ago · 3 comments

As per title.

Answer 1 · 2017-08-23T01:43:42.000Z

It would be best if we could find an ideal single point of truth for all of this kind of logic to live. Maybe that's here? I can see advantages and disadvantages.

Would like to see a healthy debate within the team about adding methods like this here in general, this one specifically, identify the tradeoffs, weigh the pros/cons, and establish a solid consensus.

Ideally before we start expanding the scope. It's easier to add than subtract once it's released.

Answer 2 · 2017-08-23T13:08:52.000Z

The reason that I can see for including this here is that in order to create the protected header in the first place we need a few key pieces of information which are all available/can be inferred from from the JWK. Notably a protected header should have an `alg` and a `kid` and then some additional properties that are not inferrable from the JWK, such as a `jku`. The alternative would be for the implementer to assemble the protected header manually (how it is currently done in `>=0.2.0`); which would most likely be done by getting the information off of the JWK anyway, or by hard-coding it to work with a particular key type. This discussion ties into the discussion around whether or not we should be have the JWT sign, encrypt and decrypt methods call out to the JWK equivalents (anvilresearch/jwt#6).

Answer 3 · 2017-08-23T13:25:29.000Z

It's also good to have this here because we can do some validation of header parameters to key material and enforce things like trying to use ES256 "alg" with an RSA key. I like having the responsibility here. It seems like it may result in some superficial duplication, as with the adapter pattern we use in JWA and webcrypto, but also seems to fit with the goal of limiting opportunity for misuse.

As a tangential and probably easily dismissed consideration, I wonder if we should support any kind of interchangeability of these constituent parts with other JOSE libs? Probably not, but it's perhaps worth explicitly stating the reasons in either case.