Re: [jose] Allow compression of plain and JWS too?

[John Bradley <[e-mail]>]

On 2012-06-03, at 9:38 PM, Manger, James H wrote:

>> Compression is required before encryption as your can't encrypt after
>> (if your encryption is any good).
>> 
>> With signing you can always leave it to transport or some other process
>> to compress it if required.
> 
> Compressing text after base64url-encoding (eg by the transport) is not nearly as effective as compressing the actual text.

I can't argue that, but it is much better than compressing after encryption.

> 
>> We did note that the http layer supports compression as well.
>> 
>> We previously came to the conclusion that compression for signing is
>> unnecessary and only adds extra code to be tested.
>> 
>> I actually had to argue quite strongly at the time to get compression
>> as a option with encryption due to the additional complexity.
> 
> If you support compression with encryption, there is no additional complexity to support compression with signing.
> Only scenarios that will only ever do signing -- with no possibility of ever needing encryption -- can potentially save some complexity. I doubt those scenarios will be common.

Again compression with encryption was a hard sell to many of the original participants like Facebook.  

Many libraries and use cases will be signing only, and they will balk at compression as a MTI.  

Making it optional will cause more interop problems than it is worth.

I honestly originally wanted compression available for both.  I have been convinced subsequently that for adoption it is better to leave it out of signing.

John B.
> 
>> So on the basis that the more mandatory to implement things we add, the
>> less likely we are to get adoption, and previous discussions around
>> some of the input documents, I am opposed to adding compression for
>> signing.
> 
> The JWS spec starts by saying it is a compact format intended for space constrained environments. It chooses terse 3-letter header element names. It defines it own alg names, partly because they are shorter than existing names.
> I am strongly in favour of including compression consistently across all the modes that a JOSE message supports (encrypted, signed, unprotected...).
> 
> --
> James Manger