On 2018-03-16 20:24, Richard Gibson wrote:
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.
It effectively depends on your objectives. #2 is not really a problem, you would typically not output canonicalized JSON, it is only used internally since there are no requirements that input is canonicalized . #3 yes, if you create bad data you can [always] screw up. It sounds BTW as a bug which presumable get fixed some day. #4 If you are targeting Node.js, Browsers, OpenAPI, and all other platforms compatible with those, JSON.stringify() seems to suffice. The JSON.canonicalize() method proposal was intended for the systems specified in #4. Perfection is often the enemy of good. Anders
[1]: _http://gibson042.github.io/canonicaljson-spec/_ [2]: http://ecma-international.org/ecma-262/7.0/#sec-tostring-applied-to-the-number-type <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 <http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring> [4]: https://tools.ietf.org/html/rfc8259#section-8.1 <https://tools.ietf.org/html/rfc8259#section-8.1> On Fri, Mar 16, 2018 at 3:09 PM, Mike Samuel <[email protected] <mailto:[email protected]>> wrote: On Fri, Mar 16, 2018 at 3:03 PM, Anders Rundgren <[email protected] <mailto:[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]> <mailto:[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-json-canonicalization-scheme.html#rfc.section.3.2.2 <https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html#rfc.section.3.2.2> <https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html#rfc.section.3.2.2 <https://cyberphone.github.io/doc/security/draft-rundgren-json-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] <mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
