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 protected]> 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 > On 21/08/15 17:22, Mike Jones wrote: >> 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 protected]] >> Sent: Friday, August 21, 2015 9:13 AM >> To: Mike Jones; [email protected] >> 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.". >>> >>> -----Original Message----- >>> From: Sergey Beryozkin [mailto:[email protected]] >>> Sent: Friday, August 21, 2015 6:09 AM >>> To: Mike Jones; [email protected] >>> Subject: Re: [jose] JWS Signing Input Options initial working group >>> draft >>> >>> Hi Mike >>> >>> The JWS JSON example at >>> >>> 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 >>> >>> shows elements in the wrong order, according to >>> >>> 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 >>> >>> the 'payload' should go first... >>> >>> thanks, Sergey >>> >>> On 10/08/15 21:01, Sergey Beryozkin wrote: >>>> 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 >>>> On 10/08/15 16:40, Mike Jones wrote: >>>>> 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 >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftool >>>>> s >>>>> .ietf.org%2fhtml%2frfc7519%23section-1&data=01%7c01%7cMichael.Jones% >>>>> 4 >>>>> 0microsoft.com%7cc0fa460926a84bb9ab2308d2aa29b0d7%7c72f988bf86f141af >>>>> 9 >>>>> 1ab2d7cd011db47%7c1&sdata=ntR%2fTNYZsAub8dOSyIKLN5%2blHNtKExYCzBj%2f >>>>> T 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. >>>>> >>>>> 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 protected]] >>>>> Sent: Monday, August 10, 2015 2:39 AM >>>>> To: Mike Jones; [email protected] >>>>> Subject: Re: [jose] JWS Signing Input Options initial working group >>>>> draft >>>>> >>>>> 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 >>>>> On 10/08/15 05:21, Mike Jones wrote: >>>>>> 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%2fto >>>>>> o >>>>>> ls.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-01%2 >>>>>> 3 >>>>>> section-5&data=01%7c01%7cMichael.Jones%40microsoft.com%7c634a8171fb >>>>>> 8 >>>>>> 74a34dbe908d2a1678cfb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata= >>>>>> F dTmmqFjXX9LBw56a1%2bk2K3dPmhp89ZqEec%2bgbAcRZA%3d >>>>>> for more on character restrictions in unencoded payloads. >>>>>> >>>>>> -- Mike >>>>>> >>>>>> -----Original Message----- >>>>>> From: jose [mailto:[email protected]] On Behalf Of Sergey >>>>>> Beryozkin >>>>>> Sent: Saturday, July 25, 2015 3:01 AM >>>>>> To: [email protected] >>>>>> 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%2fww >>>>>>> w >>>>>>> .i >>>>>>> e >>>>>>> tf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05158.html%2c&da >>>>>>> t >>>>>>> a= >>>>>>> 0 >>>>>>> 1%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d29 >>>>>>> 4 >>>>>>> d7 >>>>>>> e >>>>>>> 6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2mVSuUk74d8ZGB9gx >>>>>>> W Ry b f%2bUz5pxOXmLiUcAqL%2bVvNk%3d Nat Sakimura's review at >>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fww >>>>>>> w >>>>>>> .ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05189.html%2c >>>>>>> & >>>>>>> data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249 >>>>>>> 3 >>>>>>> 08d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zdSucPmd >>>>>>> 5 z%2b5Q5Zi%2fB61FmoUn9bhxmvatIl3R9WOdhQ%3d >>>>>>> and Matias Woloski's review at >>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fww >>>>>>> w >>>>>>> .ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05191.html&da >>>>>>> t >>>>>>> a=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308 >>>>>>> d >>>>>>> 294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=raojbpPQjvn >>>>>>> j NDynLSzSydtnVe%2fnfmWvIRTD9oXoKqA%3d >>>>>>> to start things off. >>>>>>> >>>>>>> The specification is available at: >>>>>>> >>>>>>> *https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2f >>>>>>> t >>>>>>> oo >>>>>>> l >>>>>>> s.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-00&d >>>>>>> a >>>>>>> ta >>>>>>> = >>>>>>> 01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d2 >>>>>>> 9 >>>>>>> 4d >>>>>>> 7 >>>>>>> e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=B7CCBZSw%2f9mJ35 >>>>>>> 4 >>>>>>> xj >>>>>>> 1 >>>>>>> Vplr0CKN3KjSDXHeFuUbWYx%2fs%3d >>>>>>> >>>>>>> An HTML formatted version is also available at: >>>>>>> >>>>>>> *https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fs >>>>>>> e >>>>>>> lf >>>>>>> - >>>>>>> issued.info%2fdocs%2fdraft-ietf-jose-jws-signing-input-options-00. >>>>>>> h >>>>>>> tm >>>>>>> l >>>>>>> &data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a424 >>>>>>> 9 >>>>>>> 30 >>>>>>> 8 >>>>>>> d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=H0jHGZqOrt >>>>>>> s >>>>>>> xM >>>>>>> B >>>>>>> EY3W7lFx2agz8V54RDoALY%2bxcjWV0%3d >>>>>>> >>>>>>> -- >>>>>>> Mike >>>>>>> >>>>>>> P.S. This note is also posted at >>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fse >>>>>>> l >>>>>>> f-issued.info%2f%3fp%3d1432&data=01%7c01%7cmichael.jones%40microso >>>>>>> f >>>>>>> t.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7 >>>>>>> c >>>>>>> d011db47%7c1&sdata=Ehd0PdoNA2rZx9b%2bTrPOgO5G2Nxkp1FutbTnL7cD9dg%3 >>>>>>> d >>>>>>> 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 protected] >>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >>>>>>> i >>>>>>> etf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cmichael.jones%4 >>>>>>> 0 >>>>>>> mi >>>>>>> c >>>>>>> rosoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91 >>>>>>> a >>>>>>> b2 >>>>>>> d >>>>>>> 7cd011db47%7c1&sdata=fOZrXA8pnh4Z5XsMQw5ro6Fc0%2bECj%2bKjeEziSJ5V5 >>>>>>> x >>>>>>> M% >>>>>>> 3 >>>>>>> d >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> [email protected] >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fww >>>>>> w >>>>>> .i >>>>>> etf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cmichael.jones%40 >>>>>> m >>>>>> ic >>>>>> rosoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91a >>>>>> b >>>>>> 2d >>>>>> 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%7cc0fa4609 >>> 26a84bb9ab2308d2aa29b0d7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata= >>> dGSc1zm0PKO21SYGNF%2b1l38fV3B1R7W%2f7g5efuJuzpQ%3d >>> >> > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
