Re: [jose] Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs?

[John Bradley <[e-mail]>]

We do currently have the option of RFC1952 compression of the plain text before encryption. 
Personally I think compression before encryption should be the default.  Others prefer it as a option.

We didn't add it to signing as there are existing ways to compress content in http.  

If you think it needs to be added to signing then let us know.

Regards
John Bradley



On 2012-02-09, at 4:21 PM, Steffen Yount wrote:

> Hi,
>  
> I hope this email reaches someone who can respond. I’ve included authors from the various JWT specs.
>  
> I was thinking through JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 draft spec ( http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03 ) while researching options for a REST based SSO implementation.
>  
> One of the stated motivators for the JWT/JWS/JWE formats is compactness. And, I want compactness in my HTTP headers.
>  
> It has been pointed out that HTTP load times can be dramatically effected by relatively small amounts of data in the HTTP headers. (see:http://mike.bailey.net.au/2010/07/tcp-and-the-lower-bound-of-web-performance/ )
>  
> Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs?
>  
> My suggestion here has 2 parts, each can be considered separately:
> 1.      Add the option to apply DEFLATE compression (omitting the ZLIB header and checksum fields) on the payload before encryption/signing. (It is important to apply the compression before the encryption, since an encrypted payload will contain a bunch of pseudo-random noise that isn’t easily compressed.) This feature should be accompanied by a JWT header option to toggle compression on/off. (Maybe something like “dfl” : true/false)
> 2.      Make the DEFLATE compressed payload the default behavior only requiring the JWT header option for disabling compression.
>  
> I have tested it and found that:
> With small payloads containing only keys and values having minimal substring overlap it is possible for the DEFLATE compression to produce equivalent or larger output.
> But I have also found that:
> Payloads including keys or values with any repeated name-space parts easily achieve payload size reduction.
>  
> I believe that in common use cases compression will achieve payload size reduction, since repeated name-space parts are likely to occur:
> 1.      A number of the “reserved claim names” type keys expect content of type “StringOrURI” which are likely to have repeated name-space parts.
> 2.      The specs support the “public claim names” type key extensions which will also most likely share common base URI name-space parts.
>  
> Another benefit is that DEFLATE compression on the payload should encourage the use of unique name-spaced identifiers, since DEFLATE compression removes the payload size penalty otherwise incurred when repeating a common name-space part over and over again.
>  
> Is this doable?
>  
> Desired?
>  
> What do you think of these ideas?
>  
> Thanks for your consideration,
> -Steffen
>