Skip to content
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

Support compressed (deflate) payload #428

Open
jtara opened this issue Jun 30, 2021 · 7 comments
Open

Support compressed (deflate) payload #428

jtara opened this issue Jun 30, 2021 · 7 comments

Comments

@jtara
Copy link

jtara commented Jun 30, 2021

See: RFC 7516 4.1.3

I am working with:

in Ruby.

I'm working in a constrained Ruby environment (Rhomobile platform) and ruby-jwt is well-suited for the environment since it has few dependencies. (I've used ruby-jwt before to implement openid-connect in that environment.)

Smart Health Cards are jws with I think only a small twist: the payload is compressed with DEFLATE. The signature is over the Base64 header and payload. But the payload is opaque to ruby-jwt, and it will fail trying verify claims because the payload is unintelligible to ruby-jwt.

FWIW, headers look something like:

{"zip":"DEF","alg":"ES256","kid":"7JvktUpf1_9NPwdM-70FJT3YdyTiSe2IvmVxxgDSRb0"}

Above is as implemented by California Department of Public Health for their digital Covid immunization records. (Yes the kid is real, it's no secret it's the kid of the current/only public key.)

May not take a lot to support. To read/verify, for example, would require inflating the payload after decoding the Base64, but before parsing the JSON, while still using the raw Base64 header and payload for computing the signature for signature verification. Have not examined creation/signing, as it's not something I need to do.

I've worked around for now by just using ad-hoc code and OpenSSL without ruby-jwt objects, though I do use JWT::SecurityUtils lightly. But I would love to use ruby-jwt.

Since I didn't get far with ruby-jwt I'm unclear how well supported EC is. There could be variations in the format, including possibly certificate chain.

I don't know if there are other use cases where payloads are compressed like this?

Is there an interest in supporting compressed payloads?

Willing to implement and/or help. I'd rather see this incorporated into ruby-jwt rather than making my own variant, and would be good to discuss.

Edit: I updated with RFC7516 4.1.3 reference. I left my original commentary, because Smart Health Cards are now emerging the real world, and I think may become one of the first popular use cases for compressed payload? The compression is done because these are encoded into QR Code images as one embodiment, and it makes quite a dense QR even with the compression.

@jtara
Copy link
Author

jtara commented Jun 30, 2021

I notice that RFC7515 - the JWS spec - does not provide for compression. 7516 is JWE. Not sure how the standards mesh.

Smart Health Cards use a compressed payload but they are not JWE, they are JWS.

@anakinj
Copy link
Member

anakinj commented Jul 9, 2021

Im wondering if the jwt gem is the correct place to implement the actual deflating. Maybe this gem could have a way to inject behaviour into the decoding pipeline would make sense that then could be handled in a separate JWE gem?

Would also like to move the JWK handling out of this gem into something that can be plugged into this gem.

I think the EC support is on a semi-good level when not counting some unresolved incompatibilities with some other JWT components (#412).

@jtara
Copy link
Author

jtara commented Jul 15, 2021

I've done a bit more research, and zip:deflate is not a standardized public header for JWS. (But it is for JWE).

In the context of Smart Health Cards, it is used as a private header, which is permitted.

This discussion is helpful and relevant: smart-on-fhir/health-cards Issue 128

Some plugin or finer-grain separation of concerns in some way to permit getting into the decoding pipeline would be useful. It would facilitate e.g. making a Smart Health Card-specific Gem that uses ruby-jwt to do most of the work.

@anakinj
Copy link
Member

anakinj commented Jul 15, 2021

Like the idea of making a context specific gem extending the behaviour of ruby-jwt

I could help with playing around with ideas on how to get the decode process extended. The current API is already pretty bloated so i guess that even yet another option will not make it worse, but let's see. Would you be interested in helping out with this one @jtara, it's always easier to get stuff done if there is someone giving feedback and contributing?

@anakinj
Copy link
Member

anakinj commented Jul 15, 2021

Left something in that #434. Not even close to production ready, but maybe a path that could be taken?

@anakinj
Copy link
Member

anakinj commented Dec 27, 2021

@jtara I've played around with the idea a little more. Would appreciate some input on #460. Got a simple Smart Health Card use case working with the capabilities implemented: https://github.com/jwt/ruby-jwt/pull/460/files#diff-d8d789567978973190503f1f875cbc6a0b6e53a3dc37946ea992bba213282761

@lindes
Copy link

lindes commented Jan 9, 2022

Would appreciate some input on #460. Got a simple Smart Health Card use case working

Cool! Thanks for doing this, @anakinj! I have a similar use case to @jtara, and will try to take a look at this, and let you know how it goes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants