W3C home > Mailing lists > Public > public-interledger@w3.org > January 2017

Re: JSON-RPC vs. YASMIN. Was: A Critical Analysis of REST APIs for "Transaction Systems"

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Mon, 30 Jan 2017 17:56:08 +0100
To: David Nicol <davidnicol@gmail.com>
Cc: Interledger Community Group <public-interledger@w3.org>
Message-ID: <ea4f202e-2c72-1d40-cf44-4653cab34406@gmail.com>
On 2017-01-30 16:49, David Nicol wrote:
> having just read that linked document, it seems like the missing piece is a requirement for normalizing the JSON some how before making the digest which will get signed. Strong normalization before digestion is needed to have meaningful signatures on JSON data. This can mean concatenating some subset of the elements of the message in some particular order -- essentially rewriting it as Bencoded, just to sign it -- or normalizing the JSON in such a way that the consumer of the JSON can renormalize the data structure they're going to get in such a way that they can check its digest, and then its signature.

That's correct.  YASMIN's signature scheme does a "short cut" by relying on the serialization method defined by ECMAScript which is implemented in Browsers, Node.js, and in the libraries mentioned in the YASMIN document.   Not everybody agrees that is a great idea (since it obviously doesn't work with every JSON tool out there), but not everybody finds that encapsulating JSON objects in Base64Url as required by the to date only "real" JSON related signature standard is a very cool idea either :-)

>
> One reference on this old problem http://stackoverflow.com/questions/4670494/how-to-cryptographically-hash-a-json-object does name JSON-LD as an existing variant with a well-defined canonical form.

If you are referring to the JSON-LD signature scheme, it does (IIUC...) things that IMO are wrong because it doesn't only sign "the JSON bytes", but the canonicalized RDF graph.  Why is that "wrong" you may wonder, right? Well, it makes the signature scheme unnecessary brittle as well as tied to JSON-LD.  If the RDF canonicalization method is important it should be fitted to every JSON-LD message (signed or unsigned), as a specific property, preferably holding a hash of the canonicalized graph as well.

Anyway, that the W3C Web Payment activity haven't yet defined or suggested a signature method indicates that this topic is somewhat "difficult".

Anders

>
>
> On Mon, Jan 30, 2017 at 12:08 AM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     Here is the intended YASMIN RPC mapping system:
>     https://cyberphone.github.io/doc/web/yasmin.html#apimapping <https://cyberphone.github.io/doc/web/yasmin.html#apimapping>
>
>     It doesn't seem to benefit by adding "jsonrpc" or "params" properties since all core characteristics (platform/audience/transport/security/etc) of YASMIN messages is supposed to be (implicitly) provided by the "@context" URI.
>
>     How you can add signature support to an "API" (in a practical way) is still not addressed...
>     In message-oriented YASMIN-powered applications this is trivial: you create the message and then sign it.
>
>     Anders
>
>
>
>
> -- 
> "Have you taken yourself seriously today?" -- the gravity clown
Received on Monday, 30 January 2017 16:56:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 30 January 2017 16:56:53 UTC