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

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.

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.


On Mon, Jan 30, 2017 at 12:08 AM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> Here is the intended YASMIN RPC mapping system:
> 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