Support for compressed tokens

[inferiorhumanorgans]

I'm working on a crate to decode SMART Health Cards. Per their spec, these are their requirements:

• JWS Header
  • header includes alg: "ES256"
  • header includes zip: "DEF"
  • header includes kid equal to the base64url-encoded (see section 5 of RFC4648) SHA-256 JWK Thumbprint of the key (see RFC7638)
• JWS Payload
  • payload is minified (i.e., all optional whitespace is stripped)
  • payload is compressed with the DEFLATE (see RFC1951) algorithm before being signed (note, this should be "raw" DEFLATE compression, omitting any zlib or gz headers)

Previously I've hacked up a copy of 8-beta2, but before I work on bringing this up to date with the current version of jsonwebtoken, is this something you'd entertain a PR for or is it out of scope for the crate?

[Keats]

Definitely out of scope

[inferiorhumanorgans]

The problem I've run into is that the Header struct doesn't allow access to arbitrary headers (e.g. JWS §4.2, JWE § 4.1) and only allows access to a subset of the defined headers. In this case I'm after the zip header (JWS § 4.1.3) which would allow inflating compressed JWE objects as a external trait.

[Keats]

We could dump all other fields not part of the spec in a hashmap? I'd take a PR for that if that's not a breaking change.

[inferiorhumanorgans]

Sure, however I think there are only two registered headers not covered by the struct: crit (JWS § 4.1.11) and zip (JWE § 4.1.3) so it would come down to whether it's worth potential allocation or if it's worth carrying around a couple extra fields for the most common cases.

[Keats]

I think we want to add crit at least since it's part of JWS. zip is simple and can be deserialize to an enum {Deflate, Other(String)} if we wanted and enc should be an enum as well

[inferiorhumanorgans]

Sounds great.

[Keats]

It would have to come from a PR though, and that's a breaking change