Our project has recently got the initial JWE Serialization code added in (from FH Köln contributors).

I agree with Fraser. It's an obvious case of the premature optimization, we are talking about saving 10-15 bytes of the payload at the cost of introducing two JWS Serilaization variants with the flattened option mostly duplicating what JWS Compact Serialization can do.

It won't affect us much because the default JSON parsing in our case is not 'stream-aware'. Probably not a big deal over all but I just wanted to support Fraser's comments

Sergey



On 29/10/14 04:25, Mike Jones wrote:
Thank you for your feedback, Fraser.  It would be useful to hear from others 
who have implemented the JSON Serializations whether they agree with Fraser or 
Richard.

                                -- Mike

P.S.  The list you sent it to reached the editors and chairs.  The 
[email protected] list reaches the whole JOSE working group.

-----Original Message-----
From: Fraser Tweedale [mailto:[email protected]]
Sent: Tuesday, October 28, 2014 9:11 PM
To: [email protected]
Subject: draft-ietf-jose-json-web-signature ; flattened serialization

Hello,

(I am not familiar with IETF WG processes so I hope I am communicating in a 
useful way and in the right place.)

JWS draft 36 adds a "flattened JWS syntax" for the case where there is a single 
signature.  A similar change was made for JWE in the single recipient case.

Richard Barnes proposed these changes on the following basis:

     ``I've had several implementors trying to use JWS in the JSON
     serialization ask why it was necessary to include a "signatures"
     array in cases where there's only one signer.  It seems like this is
     going to be a major barrier to deployment and re-use.''

I am the author of a Haskell JOSE library
(http://hackage.haskell.org/package/jose) and object to these changes on the 
following bases:

- They add substantial complexity to the parsing of JWS and JWE
   objects (which is already complex).

- The nature of the "optimisation" for the single-signature case is
   unclear.  If the optimisation is for compactness, this is obviated
   by "7.2. JWE JSON Serialization" which states ``This
   representation is neither optimized for compactness nor
   URL-safe.''  If the optimisation is for simplicity, it is a false
   economy.

- The fact that implementors were asking about this part of the spec
   does not imply an impediment to deployment and re-use.  (Perhaps
   comments to this effect were in fact made, but as written the
   justification is speculative.)

The wish for a "simpler" serialization for a common use case is understandable, but this is a case 
of "be careful what you wish for".  Commentary to the effect of "the signatures array is used 
even when there is a single signature/recipient to keep parsing as simple as possible" would give 
implementors the answer to this question and relieve them of the additional complexity required to support 
the Flattened Serialization in addition to the General Serialization.

Please consider reverting this recent change to the specification.

Regards,

Fraser Tweedale

_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to