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

From: John Bradley <[email-masked]>
Date: Thu, 9 Feb 2012 18:03:06 -0300

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
>

---

From: John Bradley <[email-masked]>
Date: Fri, 10 Feb 2012 18:45:38 -0300

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:[email-masked]] 
> 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; [email-masked]
> Subject: Re: Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE 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.
> >

---

From: Mike Jones <[email-masked]>
Date: Fri, 10 Feb 2012 22:45:05 +0000

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:[email-masked]]
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; [email-masked]
Subject: Re: Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs?

John B.

Hi John,

My use case:

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:[email-masked]]<mailto:[mailto:[email-masked]]>
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; [email-masked]<mailto:[email-masked]>
Subject: Re: Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs?

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.
>
> 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)
> 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.
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 16 Feb 2012 20:25:11 +0000

Yes.  If you're not already a member, you should join the IETF JOSE working group mailing list at https://www.ietf.org/mailman/listinfo/jose and discuss this feature request there.  Ideally, you should propose specific syntax and semantics for the proposed addition so it's concrete and can be unambiguously understood by the working group participants.

                                                            Cheers,
                                                            -- Mike

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

I believe this "zip" option can be added to the spec without implying yet another mandatory-to-implement feature. We have the example of only supporting a subset of the encryption and signature algorithms and then providing a discovery process for determining which of them are supported. Compression algorithms could be optionally supported in this same way.

My use-case is really about re-using JWT/JWS/JWE as simple and well defined assertion format. I realize that this use-case is beyond the targeted usage of JWT/JWS/JWE as the format for OpenID Connect id_tokens. So, I will understand if my use case isn't deemed important enough to warrant changes to the specs.

That said: I do believe that it does make sense to compress the content of the JWS payload part for my implementation. (I have this implemented)

Rather than implementing my own proprietary extension to JWS for this purpose, I would prefer to do it using a standard option.

Is there anything I can do to encourage consensus and get the WG to add this "zip" option to the spec for JWT/JWS headers?

Thank again,
-Steffen

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

                                                                -- Mike

From: John Bradley [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
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; [email-masked]<mailto:[email-masked]>
Subject: Re: Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs?

John B.

Hi John,

My use case:

Thanks again,
-Steffen

-----Original Message-----
From: John Bradley [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
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; [email-masked]<mailto:[email-masked]>
Subject: Re: Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs?

Regards
John Bradley