Subject: Re: [jose] JWS Signing Input Options initial working group draft

From: Mike Jones <[email-masked]>
Date: Mon, 10 Aug 2015 04:21:43 +0000

You can't use an unencoded non-detached JSON payload using the JWS Compact Serialization because it uses characters that aren't URL-safe, such as "{".  For that reason, the spec now makes it clear that JWTs cannot use the "b64":false option.

You *can* use JSON payloads with the JWS JSON Serialization.  Any double-quote characters in the JSON would have to be quoted - typically using \" - so that the double-quotes don't terminate the "payload" value.  See the new section https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-01#section-5 for more on character restrictions in unencoded payloads.

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Sergey Beryozkin
Sent: Saturday, July 25, 2015 3:01 AM
To: [email-masked]
Subject: Re: [jose] JWS Signing Input Options initial working group draft

Hi, can you please add an example showing a b64 header affecting JWS JSON payload ? I can imagine how it will look like but it is good to see an example that can be tested locally...

Cheers, Sergey
On 23/07/15 19:17, Mike Jones wrote:
> The initial working group version of JWS Signing Input Options has 
> been posted.  It contains no normative changes from
> draft-jones-jose-jws-signing-input-options-00
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fself-issued.info%2f%3fp%3d1398&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zQrvoO4fBOa1nUomMVoBT862ELgRpuIQ%2fBaV17ijH7Y%3d>.
>
> Let the working group discussions begin!  I particularly call your 
> attention to Martin Thomson's review at 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ie
> tf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05158.html%2c&data=0
> 1%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e
> 6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2mVSuUk74d8ZGB9gxWRyb
> f%2bUz5pxOXmLiUcAqL%2bVvNk%3d Nat Sakimura's review at 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05189.html%2c&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zdSucPmd5z%2b5Q5Zi%2fB61FmoUn9bhxmvatIl3R9WOdhQ%3d and Matias Woloski's review at https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05191.html&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=raojbpPQjvnjNDynLSzSydtnVe%2fnfmWvIRTD9oXoKqA%3d to start things off.
>
> The specification is available at:
>
> *https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftool
> s.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-00&data=
> 01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7
> e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=B7CCBZSw%2f9mJ354xj1
> Vplr0CKN3KjSDXHeFuUbWYx%2fs%3d
>
> An HTML formatted version is also available at:
>
> *https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-
> issued.info%2fdocs%2fdraft-ietf-jose-jws-signing-input-options-00.html
> &data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308
> d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=H0jHGZqOrtsxMB
> EY3W7lFx2agz8V54RDoALY%2bxcjWV0%3d
>
>                                                              -- Mike
>
> P.S.  This note is also posted at 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2f%3fp%3d1432&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ehd0PdoNA2rZx9b%2bTrPOgO5G2Nxkp1FutbTnL7cD9dg%3d and as @selfissued <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fselfissued&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=54dOa%2fD75zbVVpfbjYFAq4yL9zmJ7q9p2qIbJRY%2flIA%3d>.
>
>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cmichael.jones%40mic
> rosoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d
> 7cd011db47%7c1&sdata=fOZrXA8pnh4Z5XsMQw5ro6Fc0%2bECj%2bKjeEziSJ5V5xM%3
> d
>

_______________________________________________
jose mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fOZrXA8pnh4Z5XsMQw5ro6Fc0%2bECj%2bKjeEziSJ5V5xM%3d

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 10 Aug 2015 10:39:10 +0100

Hi, thanks for adding the JWS JSON (flattened serialization) example,

I thought the earlier text was also clear about having to use the 
detached payloads in case of JWS Compact.

Re the new JWT restriction.

I know JWT is meant to be used primarily in OAuth2 contexts as a token 
or grant (or as one of token or grant property) representation and hence 
it is JWS Compact.

But I wonder, should this particular text effectively block the possible 
future use of JWT in (JWS JSON) message payloads...

Cheers, Sergey

---

From: Mike Jones <[email-masked]>
Date: Mon, 10 Aug 2015 15:40:21 +0000

Hi Sergey,

Actually, the JWT restriction to only using the compact serialization is already in the JWT spec itself.  The last sentence of the first paragraph of the introduction at http://tools.ietf.org/html/rfc7519#section-1 says "JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization".  The new text in the JWS Unsigned Payload Option spec just adds the restriction that JWTs are to continue to use RFC7515 as written - base64url encoding the JWT claims as they always have been - for interop purposes.

That doesn't mean that other applications can't use JWS to sign detached unencoded JSON payloads with the "b64":false option using either JWS serialization.

Does that address what you were thinking about or do you still have concerns?

				-- Mike

-----Original Message-----
From: Sergey Beryozkin [mailto:[email-masked]] 
Sent: Monday, August 10, 2015 2:39 AM
To: Mike Jones; [email-masked]
Subject: Re: [jose] JWS Signing Input Options initial working group draft

I thought the earlier text was also clear about having to use the detached payloads in case of JWS Compact.

I know JWT is meant to be used primarily in OAuth2 contexts as a token or grant (or as one of token or grant property) representation and hence it is JWS Compact.

But I wonder, should this particular text effectively block the possible future use of JWT in (JWS JSON) message payloads...

Cheers, Sergey
On 10/08/15 05:21, Mike Jones wrote:
> You *can* use JSON payloads with the JWS JSON Serialization.  Any double-quote characters in the JSON would have to be quoted - typically using \" - so that the double-quotes don't terminate the "payload" value.  See the new section https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-01%23section-5&data=01%7c01%7cMichael.Jones%40microsoft.com%7c634a8171fb874a34dbe908d2a1678cfb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=FdTmmqFjXX9LBw56a1%2bk2K3dPmhp89ZqEec%2bgbAcRZA%3d for more on character restrictions in unencoded payloads.
>
> 				-- Mike
>
>> 6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2mVSuUk74d8ZGB9gxWRy
>> b f%2bUz5pxOXmLiUcAqL%2bVvNk%3d Nat Sakimura's review at

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 10 Aug 2015 21:01:09 +0100

Hi Mike
Thanks for the clarification, indeed it all makes sense now (I would 
like to think a bit more about JWT as JWS JSON, will send a separate 
email if anything relevant comes to mind).

Cheers, Sergey

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 21 Aug 2015 14:09:02 +0100

Hi Mike

The JWS JSON example at

https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-01#section-4.2

shows elements in the wrong order, according to

https://tools.ietf.org/html/rfc7515#section-7.2.2

the 'payload' should go first...

thanks, Sergey

On 10/08/15 21:01, Sergey Beryozkin wrote:
>> Actually, the JWT restriction to only using the compact serialization
>> is already in the JWT spec itself.  The last sentence of the first
>> paragraph of the introduction at
>> http://tools.ietf.org/html/rfc7519#section-1 says "JWTs are always
>> represented using the JWS Compact Serialization or the JWE Compact
>> Serialization".  The new text in the JWS Unsigned Payload Option spec
>> just adds the restriction that JWTs are to continue to use RFC7515 as
>> written - base64url encoding the JWT claims as they always have been -
>> for interop purposes.
>>
>> That doesn't mean that other applications can't use JWS to sign
>> detached unencoded JSON payloads with the "b64":false option using
>> either JWS serialization.
>>
>> or grant (or as one of token or grant property) representation and
>> hence it is JWS Compact.
>>
>> But I wonder, should this particular text effectively block the
>> possible future use of JWT in (JWS JSON) message payloads...
>>
>> Cheers, Sergey
>>> You can't use an unencoded non-detached JSON payload using the JWS
>>> Compact Serialization because it uses characters that aren't
>>> URL-safe, such as "{".  For that reason, the spec now makes it clear
>>> that JWTs cannot use the "b64":false option.
>>>
>>> You *can* use JSON payloads with the JWS JSON Serialization.  Any
>>> double-quote characters in the JSON would have to be quoted -
>>> typically using \" - so that the double-quotes don't terminate the
>>> "payload" value.  See the new section
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-01%23section-5&data=01%7c01%7cMichael.Jones%40microsoft.com%7c634a8171fb874a34dbe908d2a1678cfb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=FdTmmqFjXX9LBw56a1%2bk2K3dPmhp89ZqEec%2bgbAcRZA%3d
>>> for more on character restrictions in unencoded payloads.
>>>
>>>                 -- Mike
>>>
>>> Hi, can you please add an example showing a b64 header affecting JWS
>>> JSON payload ? I can imagine how it will look like but it is good to
>>> see an example that can be tested locally...
>>>
>>> Cheers, Sergey
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05189.html%2c&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zdSucPmd5z%2b5Q5Zi%2fB61FmoUn9bhxmvatIl3R9WOdhQ%3d
>>>> and Matias Woloski's review at
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05191.html&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=raojbpPQjvnjNDynLSzSydtnVe%2fnfmWvIRTD9oXoKqA%3d
>>>> to start things off.
>>>>
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2f%3fp%3d1432&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ehd0PdoNA2rZx9b%2bTrPOgO5G2Nxkp1FutbTnL7cD9dg%3d
>>>> and as @selfissued
>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fselfissued&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=54dOa%2fD75zbVVpfbjYFAq4yL9zmJ7q9p2qIbJRY%2flIA%3d>.
>>>>
>>>>
>>>>
>>>>

-- 
Sergey Beryozkin

Talend Community Coders

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 21 Aug 2015 16:21:07 +0100

As far as JWS JSON is concerned - would it be restricted to a container 
with a single signature only (flattened or with the single element 
signatures array) ?

Thanks, Sergey

---

From: Mike Jones <[email-masked]>
Date: Fri, 21 Aug 2015 16:07:24 +0000

JSON does not specify the order of the fields, so any order is legal.  Per http://rfc7159.net/rfc7159#rfc.section.1 "An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array.".

-----Original Message-----
From: Sergey Beryozkin [mailto:[email-masked]] 
Sent: Friday, August 21, 2015 6:09 AM
To: Mike Jones; [email-masked]
Subject: Re: [jose] JWS Signing Input Options initial working group draft

Hi Mike

The JWS JSON example at

thanks, Sergey

On 10/08/15 21:01, Sergey Beryozkin wrote:
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools
>> .ietf.org%2fhtml%2frfc7519%23section-1&data=01%7c01%7cMichael.Jones%4
>> 0microsoft.com%7cc0fa460926a84bb9ab2308d2aa29b0d7%7c72f988bf86f141af9
>> 1ab2d7cd011db47%7c1&sdata=ntR%2fTNYZsAub8dOSyIKLN5%2blHNtKExYCzBj%2fT
>> M1T4QE%3d says "JWTs are always represented using the JWS Compact 
>> Serialization or the JWE Compact Serialization".  The new text in the JWS Unsigned Payload Option spec just adds the restriction that JWTs are to continue to use RFC7515 as written - base64url encoding the JWT claims as they always have been - for interop purposes.
>>
>> I know JWT is meant to be used primarily in OAuth2 contexts as a 
>> token or grant (or as one of token or grant property) representation 
>> and hence it is JWS Compact.
>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftoo
>>> ls.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-01%23
>>> section-5&data=01%7c01%7cMichael.Jones%40microsoft.com%7c634a8171fb8
>>> 74a34dbe908d2a1678cfb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=F
>>> dTmmqFjXX9LBw56a1%2bk2K3dPmhp89ZqEec%2bgbAcRZA%3d
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww
>>>> .i
>>>> e
>>>> tf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05158.html%2c&dat
>>>> a=
>>>> 0
>>>> 1%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294
>>>> d7
>>>> e
>>>> 6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2mVSuUk74d8ZGB9gxW
>>>> Ry b f%2bUz5pxOXmLiUcAqL%2bVvNk%3d Nat Sakimura's review at 
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww
>>>> .ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05189.html%2c&
>>>> data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a42493
>>>> 08d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zdSucPmd5
>>>> z%2b5Q5Zi%2fB61FmoUn9bhxmvatIl3R9WOdhQ%3d
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww
>>>> .ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05191.html&dat
>>>> a=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d
>>>> 294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=raojbpPQjvnj
>>>> NDynLSzSydtnVe%2fnfmWvIRTD9oXoKqA%3d
>>>> to start things off.
>>>>
>>>> *https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ft
>>>> oo
>>>> l
>>>> s.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-00&da
>>>> ta
>>>> =
>>>> 01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d29
>>>> 4d
>>>> 7
>>>> e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=B7CCBZSw%2f9mJ354
>>>> xj
>>>> 1
>>>> *https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fse
>>>> lf
>>>> -
>>>> issued.info%2fdocs%2fdraft-ietf-jose-jws-signing-input-options-00.h
>>>> tm
>>>> l
>>>> &data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249
>>>> 30
>>>> 8
>>>> d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=H0jHGZqOrts
>>>> xM
>>>> B
>>>> Mike
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsel
>>>> f-issued.info%2f%3fp%3d1432&data=01%7c01%7cmichael.jones%40microsof
>>>> t.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7c
>>>> d011db47%7c1&sdata=Ehd0PdoNA2rZx9b%2bTrPOgO5G2Nxkp1FutbTnL7cD9dg%3d
>>>> and as @selfissued
>>>> etf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cmichael.jones%40
>>>> mi
>>>> c
>>>> rosoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91a
>>>> b2
>>>> d
>>>> 7cd011db47%7c1&sdata=fOZrXA8pnh4Z5XsMQw5ro6Fc0%2bECj%2bKjeEziSJ5V5x
>>>> M%
>>>> 3
>>>> d
>>>>
>>>

--
Sergey Beryozkin

Talend Community Coders
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcoders.talend.com%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7cc0fa460926a84bb9ab2308d2aa29b0d7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=dGSc1zm0PKO21SYGNF%2b1l38fV3B1R7W%2f7g5efuJuzpQ%3d

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 21 Aug 2015 17:12:45 +0100

Sure, I thought JWS JSON objects were more restrictive. The order shown 
in the JWS spec allows for streaming, on the -out and possibly -in side.
Is it really important to go pure JSON as far as the order of JWS JSOn 
object properties is concerned ?

Cheers, Sergey

---

From: Mike Jones <[email-masked]>
Date: Fri, 21 Aug 2015 16:22:41 +0000

A JWS parser supporting the JWS JSON Serialization needs to accept fields in any order.  To my memory, no one suggested during the working group discussions that we try to create an "ordered JSON".

That being said, the order of the fields in the JWS Compact Serialization is fixed, with the order chosen to enable streaming.

				Best wishes,
				-- Mike

-----Original Message-----
From: Sergey Beryozkin [mailto:[email-masked]] 
Sent: Friday, August 21, 2015 9:13 AM
To: Mike Jones; [email-masked]
Subject: Re: [jose] JWS Signing Input Options initial working group draft

Sure, I thought JWS JSON objects were more restrictive. The order shown in the JWS spec allows for streaming, on the -out and possibly -in side.
Is it really important to go pure JSON as far as the order of JWS JSOn object properties is concerned ?

Cheers, Sergey

On 21/08/15 17:07, Mike Jones wrote:
> JSON does not specify the order of the fields, so any order is legal.  Per https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2frfc7159.net%2frfc7159%23rfc.section.1&data=01%7c01%7cMichael.Jones%40microsoft.com%7c99566bdc28b14158a5cf08d2aa435bc5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gu7eQZbPLbgUD%2baUaPP5ra97nDHmymt59GEAcyv0pnc%3d "An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array.".
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools
> .ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-01%23sect
> ion-4.2&data=01%7c01%7cMichael.Jones%40microsoft.com%7c99566bdc28b1415
> 8a5cf08d2aa435bc5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4S5cS0q
> Bo1m5hhOO%2f3NRC7b2BkX%2fAa%2b%2ffX4JmlzF%2fM4%3d
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools
> .ietf.org%2fhtml%2frfc7515%23section-7.2.2&data=01%7c01%7cMichael.Jone
> s%40microsoft.com%7c99566bdc28b14158a5cf08d2aa435bc5%7c72f988bf86f141a
> f91ab2d7cd011db47%7c1&sdata=K7mZVTTYqKpykvnEbcrtIDSHl01NJhEiXFKlKRmLp0
> g%3d
>
>>> Actually, the JWT restriction to only using the compact 
>>> serialization is already in the JWT spec itself.  The last sentence 
>>> of the first paragraph of the introduction at 
>>> 1ab2d7cd011db47%7c1&sdata=ntR%2fTNYZsAub8dOSyIKLN5%2blHNtKExYCzBj%2f
>>> T M1T4QE%3d says "JWTs are always represented using the JWS Compact 
>>>> URL-safe, such as "{".  For that reason, the spec now makes it 
>>>> clear that JWTs cannot use the "b64":false option.
>>>>
>>>> 74a34dbe908d2a1678cfb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=
>>>> F dTmmqFjXX9LBw56a1%2bk2K3dPmhp89ZqEec%2bgbAcRZA%3d
>>>> Hi, can you please add an example showing a b64 header affecting 
>>>> JWS JSON payload ? I can imagine how it will look like but it is 
>>>> good to see an example that can be tested locally...
>>>>
>>>> Cheers, Sergey
>>>>> 6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2mVSuUk74d8ZGB9gx
>>>>> W Ry b f%2bUz5pxOXmLiUcAqL%2bVvNk%3d Nat Sakimura's review at 
>>>>> 08d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zdSucPmd
>>>>> 5 z%2b5Q5Zi%2fB61FmoUn9bhxmvatIl3R9WOdhQ%3d
>>>>> 294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=raojbpPQjvn
>>>>> j NDynLSzSydtnVe%2fnfmWvIRTD9oXoKqA%3d
>>>>> to start things off.
>>>>>
>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fww
>>>> w
>>>> .i
>>>> m
>>>> ic
>>>> b
>>>> 2d
>>>> M
>>>> %3
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcoders
> .talend.com%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7cc0fa4609
> 26a84bb9ab2308d2aa29b0d7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=
> dGSc1zm0PKO21SYGNF%2b1l38fV3B1R7W%2f7g5efuJuzpQ%3d
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 21 Aug 2015 17:31:42 +0100

Sounds good, thanks, we do have a JWS JSON writer that does the best 
effort at streaming, with the payload property being first, though I 
have to admit I did not try implementing streaming on the read side.
Either way, supporting the random order of properties on the read side 
for the interoperability would not be a problem

Cheers, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 21 Aug 2015 17:33:09 +0100

I guess the b64 value would simply have to be the same in all the 
protected headers if it is a multiple signature container...

Thanks, Sergey

---

From: John Bradley <[email-masked]>
Date: Fri, 21 Aug 2015 13:48:47 -0300

The order of the b64 encoded segments is fixed for streaming.  For sending you can do the b64 encoding on the fly.   For receiving you probably want to buffer the header b64 and check the JSON for validity.  
The streaming that the recipient can do is calculating the hash over the segments, however you need to read the JSON header first to select the correct hash function.

Given that you really need to read the whole JSON header object first, the ordering of the elements in the object were not considered important and a client needs to accept them in any order.

I understand what you are trying to optimize, and it works for sending but receiving needs some buffering.

John B.

> On Aug 21, 2015, at 1:31 PM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Sounds good, thanks, we do have a JWS JSON writer that does the best effort at streaming, with the payload property being first, though I have to admit I did not try implementing streaming on the read side.
> Either way, supporting the random order of properties on the read side for the interoperability would not be a problem
> 
> Cheers, Sergey
> https://www.ietf.org/mailman/listinfo/jose