Though ECMAScript JSON.stringify may suffice for certain Javascript-centric use cases or otherwise restricted subsets thereof as addressed by JOSE, it is not suitable for producing canonical/hashable/etc. JSON, which requires a fully general solution such as [1]. Both its number serialization [2] and string serialization [3] specify aspects that harm compatibility (the former having arbitrary branches dependent upon the value of numbers, the latter being capable of producing invalid UTF-8 octet sequences that represent unpaired surrogate code points—unacceptable for exchange outside of a closed ecosystem [4]). JSON is a general *language-agnostic* interchange format, and ECMAScript JSON.stringify is *not* a JSON canonicalization solution.
[1]: *http://gibson042.github.io/canonicaljson-spec/ <http://gibson042.github.io/canonicaljson-spec/>* [2]: http://ecma-international.org/ecma-262/7.0/#sec- tostring-applied-to-the-number-type [3]: http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring [4]: https://tools.ietf.org/html/rfc8259#section-8.1 On Fri, Mar 16, 2018 at 3:09 PM, Mike Samuel <[email protected]> wrote: > > > On Fri, Mar 16, 2018 at 3:03 PM, Anders Rundgren < > [email protected]> wrote: > >> On 2018-03-16 19:51, Mike Samuel wrote: >> >>> >>> >>> On Fri, Mar 16, 2018 at 2:43 PM, Anders Rundgren < >>> [email protected] <mailto:[email protected]>> >>> wrote: >>> >>> On 2018-03-16 19:30, Mike Samuel wrote: >>> >>> 2. Any numbers with minimal changes: dropping + signs, >>> normalizing zeros, >>> using a fixed threshold for scientific notation. >>> PROS: supports whole JSON value-space >>> CONS: less useful for hashing >>> CONS: risks loss of precision when decoders decide based >>> on presence of >>> decimal point whether to represent as double or int. >>> >>> >>> Have you actually looked into the specification? >>> https://cyberphone.github.io/doc/security/draft-rundgren-jso >>> n-canonicalization-scheme.html#rfc.section.3.2.2 < >>> https://cyberphone.github.io/doc/security/draft-rundgren-js >>> on-canonicalization-scheme.html#rfc.section.3.2.2> >>> ES6 has all what it takes. >>> >>> >>> Yes, but other notions of canonical equivalence have been mentioned here >>> so reasons to prefer one to another seem in scope. >>> >> >> Availability beats perfection anytime. This is the VHS (if anybody >> remember that old story) of canonicalization and I don't feel too bad about >> that :-) > > > Perhaps. Any thoughts on my question about the merits of "Hashable" vs > "Canonical"? > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
