Payload Compression

[panva]

I think it would be useful if payload compression was possible with e.g. using a c suffix (v1c.[purpose].).

One compression algorithm (raw inflate/deflate v1c, brotli v1b, gzip v1g) would be used?

Payload processing for these versions would change to

• serialize JSON
• deflate
• sign or encrypt

or

• verify or decrypt
• inflate
• JSON parse

This is technically possible today if a library exposes a raw payload construct but this approach lacks negotioation between the issuer and recipient that compression is used.

Feel free to take liberty with the suggested scheme.

[paragonie-security]

We were originally intending on the suffix to mean "alternative encoding to JSON", rather than a compression flag. The main reason is that the flag will affect how systems are expecting the footer to be encoded too.

If you're not deviating from JSON, it might be easier to just specify this as a footer attribute.

Generally speaking, compression and cryptography don't mix well. See also BREACH, CRIME, and this iMessage attack.

If we decide to specify this, we should be very thoughtful about not enabling attacks.

[paragonie-security]

The best practices RFC for JWT forbids compression.

Tempting it may be for some folks to implement, we shouldn't permit this.