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

[Mike Jones <[e-mail]>]

Compression isn't specified in JWS thus far because every mandatory-to-implement feature makes implementations that much harder to do and simplicity is a core goal.  That being said, if the WG has a clear and compelling need for this that outweighs the complexity downside, it could of course be added.  Discussion?

                                                                -- Mike

From: John Bradley [mailto:[e-mail]]
Sent: Friday, February 10, 2012 1:46 PM
To: Steffen Yount
Cc: Mike Jones; Brian Campbell; Chuck Mortimore; Dirk Balfanz; Yaron Goland; John Panzer; Nat Sakimura; Paul Tarjan; Eric Rescorla; Joe Hildebrand; [e-mail]
Subject: Re: Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs?

The reason I had for originally proposing LZ77 with 32 bitCRC was to provide an integrity check against tampering when using AES-CBC encryption.

If we make encryption with integrity the default I don't have any issue with dropping the internal CRC.

I can see your point about compressing signed tokens in the header being easier if it is directly supported by the spec.

I would not be opposed to that change if there is consensus in the WG to make it.

John B.


On 2012-02-09, at 11:32 PM, Steffen Yount wrote:


Hi John,

Thanks for pointing that out, I've located that reserved header parameter "zip" in the JWE spec. (http://tools.ietf.org/html/draft-jones-json-web-encryption-02#section-4.1 )

Yes, I think this "zip" header should be added for JWS signing as well.

My use case:
I'm looking at using JWS as a Bearer token for HTTP Authorization and encoding multiple "scope" grants into the token. The clients will be treating the token as opaque data and it is not clear that they will know if a server supports HTTP compression when their requests are made. So, I'm expecting that the client's HTTP requests will be submitted uncompressed.

Since I can't rely on HTTP level compression, I would like to compress the payload before it is used in the request. Compression should reduce my token size considerably, since the multiple scope grants will be repeating name-space parts.

Would it be possible to specify a "zip"="DEFLATE" option too for both JWS and JWE?
*        This option should rely only on RFC1951 compression without a ZLIB header or checksum field. (a.k.a: DEFLATE with the "nowrap" option)
*        The difference is 18 bytes of GZIP wrapper data overhead.
*        When dealing with small payloads containing only few repeating parts, these 18 bytes are likely to leave the compressed output longer than the input.

Thanks again,
-Steffen

-----Original Message-----
From: John Bradley [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>
Sent: Thursday, February 09, 2012 1:03 PM
To: Steffen Yount
Cc: Michael B. Jones; Brian Campbell; Chuck Mortimore; Dirk Balfanz; Yaron Y. Goland; John Panzer; Nat Sakimura; Paul Tarjan; Eric Rescorla; Joe Hildebrand; [e-mail]<mailto:[e-mail]>
Subject: Re: Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs?

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
>