A follow-up: if this optimization stays then IMHO it has to be made
clear that it is an optional optimization, i.e, the receivers should not
expect the a JWS JSON with a single signature is optimized.
This may be off-topic, but here is a relevant story IMHO. I'm curently
maintaining a Jettison project which is a basic Java and JAXB based JSON
mapper.
Jettison is XMLStreamWriter/Reader that converts JAXB events into JSON
and vice-versa. Its main limitation is it can not figure out, when
creating JSON, if a given element is a plain JSON "key":"value" pair or
actually part of an array, unless a given key has been reported more
than once.
It can be easily checked that the single issue Jettison users most often
asked about is "why Jettison does not give me back an array in cases
where my bean has a single List element".
My point here is that it is not unusual that users will write the code
that can not distinguish between the arrays and the single elements
which happen to represent the arrays too. Hence this optimization needs
to be optional IMHO...
Thanks, Sergey
On 29/10/14 10:04, Sergey Beryozkin wrote:
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
