I have need of this for projects inside and outside the IETF. So I would be highly in favor of a BOF or side meeting to work on this and talk through what is possible, what is needed, and where we go from here.
Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." > On Dec 9, 2018, at 3: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
