Without addressing the rest of the question, your assertion that a hypothetical JSON working group approach to c14n would take a schema-driven approach is unsupported by evidence and I think very unlikely. If only because there is no JSON schema technology that has anything like consensus support.
On Sun, Dec 9, 2018 at 2:22 AM Anders Rundgren < [email protected]> wrote: > On 2018-12-07 19:25, Bret Jordan wrote: > > Thanks for the test data. Are you going to request a side meeting for > Prague? > > That's a good question. Since few have read the existing (somewhat > constrained), serialization-only proposal [1], I'm considering other > alternatives [4,5] > > As you know REST [2] is currently held as the only "real" way architecting > Web applications. In spite of that, there is no standard for signing REST > requests but signed REST requests are still used in the wild including by > Amazon [3]. > > A rebooted JSON WG would likely settle on a full-fledged counterpart to > XML's "CN14" which I have no interest in because it presumes that the > canonicalization process is schema driven for both parsing and > serialization, making deployment much more complex. > > Anyway, IF there actually is GENUINE interest in a BoF session in Prague, > could you guys on the list indicate your interest? > > Thanx, > Anders > > 1] > https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01 > > 2] https://en.wikipedia.org/wiki/Representational_state_transfer > > 3] > https://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html > > 4] https://www.rfc-editor.org/about/independent/ > > 5] Ignoring the standards process and rather let associated applications > like https://cyberphone.github.io/doc/two-visions-4-mobile-payments.pdf > set a de-facto standard. > > > > > > > Bret > > > > Sent from my Commodore 128D > > > > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > > > > On Dec 7, 2018, at 9:23 AM, Anders Rundgren < > [email protected] <mailto:[email protected]>> > wrote: > > > >> Since XML Canonicalization has a reputation of not only being brittle > but also terribly slow, I tested JCS [1] with the following JSON file: > >> { > >> "1": {"f": {"f": "hi","F": 5} ,"\n": 56.0}, > >> "10": { }, > >> "": "empty", > >> "a": { }, > >> "111": [ {"e": "yes","E": "no" } ], > >> "A": { } > >> } > >> > >> Expected output: > {"":"empty","1":{"\n":56,"f":{"F":5,"f":"hi"}},"10":{},"111":[{"E":"no","e":"yes"}],"A":{},"a":{}} > >> > >> Since JCS only is a serialization concept (parsing is unaffected), I > compared the execution speed of standard serialization versus canonicalized > serialization. > >> > >> Using https://www.npmjs.com/package/canonicalize the performance > penalty was about 2.4 compared to JSON.stringify(). > >> Using my homegrown JSON tools written in Java having an integrated > "canonicalize" serializer option the performance penalty was about 1.4 > >> > >> Anders > >> > >> 1] > https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01 > >> > >> _______________________________________________ > >> jose mailing list > >> [email protected] <mailto:[email protected]> > >> https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
