Re: [jose] draft-ietf-jose-json-web-signature ; flattened serialization

Sergey Beryozkin <> Wed, 12 November 2014 10:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 84A781A6F0A for <>; Wed, 12 Nov 2014 02:58:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VkiOR8F8RCpH for <>; Wed, 12 Nov 2014 02:57:59 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BB641A1B64 for <>; Wed, 12 Nov 2014 02:57:59 -0800 (PST)
Received: by with SMTP id k14so13770353wgh.15 for <>; Wed, 12 Nov 2014 02:57:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/ueKmCcyUs2/pkawbHReyTf4bdxUxPJdSFmKYZFCdSA=; b=KN3SWU4bS2eEFiujhz1jdgnxZYunwrt2uXFRX+MhQyt3EP/xaMMYdnVTjfKnzy0n93 nrIf3edMcgkVA41C68DjouHUO8Gyh1z/zY0dPmjCjhL6f4zSPAvpo+5roMBHqqC7pJMu IfgrH9VSO5zRftq6QZIrU5OAKozKgO0zV+CKvhMHYmMgA/jNsytk8YnowYj1ikTgTL+e e/fdZoEjK9DmdRWxMKiX1X/implG+GK4ougt8uQVo0GGfL5yW0koq7HDZCx2m/ALXErh 5FtgSJVR0rVBAdj6zMdXNFN4xeXvLV7zsdWL462jbxvuPte004fepNssnjpw/4vYrEWA i5qA==
X-Received: by with SMTP id yo3mr30862231wjc.60.1415789875822; Wed, 12 Nov 2014 02:57:55 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id q9sm21163806wix.6.2014. for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Nov 2014 02:57:55 -0800 (PST)
Message-ID: <>
Date: Wed, 12 Nov 2014 10:57:40 +0000
From: Sergey Beryozkin <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Mike Jones <>, Fraser Tweedale <>, "" <>, "" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Richard Barnes <>
Subject: Re: [jose] draft-ietf-jose-json-web-signature ; flattened serialization
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Nov 2014 10:58:01 -0000

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 

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
>> list reaches the whole JOSE working group.
>> -----Original Message-----
>> From: Fraser Tweedale []
>> Sent: Tuesday, October 28, 2014 9:11 PM
>> To:
>> 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
>> ( 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