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

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

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Wed, 8 Feb 2017 08:59:38 +0200
Message-ID: <CA+eFz_Ltz=ySS6mSv++dyqr8ggXcH3jYQmvXFd7yENZsMbOyNw@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Ryan Fugger <arv@ryanfugger.com>, Stefan Thomas <stefan@ripple.com>, Tony Arcieri <tony@chain.com>, David Nicol <davidnicol@gmail.com>, Interledger Community Group <public-interledger@w3.org>
If you're signing a something that has a well-known structure beforehand it
would seem that a generic canonicalization algorithm is unnecessary
overhead.

JSON is great for flexible data structures but for use cases like IPR[1]
and KEP[2] I like the proposal to simply follow the HTTP approach as
proposed in Stefan's comment [3].

[1] https://github.com/interledger/rfcs/blob/master/
0011-interledger-payment-request/0011-interledger-payment-request.md

[2] https://gist.github.com/sharafian/df7a4b7e2ff000248800b113f06f549a

[3]
https://gist.github.com/sharafian/df7a4b7e2ff000248800b113f06f549a#gistcomment-1987340


On 8 February 2017 at 07:25, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> On 2017-02-08 06:17, Ryan Fugger wrote:
>
>> How important is canonicalization in this case?  Why not just keep the
>> original
>>
> > raw message bytes around for whenever you need to verify the signature?
>
> That's what the IETF standard prescribes.  It obviously works.
>
> Not everybody accept the downsides of this approach:
> https://cyberphone.github.io/doc/security/jsonsignatures.html
>
> Anders
>
>
>
>> On Tue, Feb 7, 2017 at 7:19 PM, Stefan Thomas <stefan@ripple.com <mailto:
>> stefan@ripple.com>> wrote:
>>
>>     Great point, Tony! I think objecthash is a really good candidate for
>> us to adopt for the payment request hashing used in IPR[1] and KEP[2].
>>
>>     [1] https://github.com/interledger/rfcs/blob/master/0011-
>> interledger-payment-request/0011-interledger-payment-request.md <
>> https://github.com/interledger/rfcs/blob/master/0011-
>> interledger-payment-request/0011-interledger-payment-request.md>
>>
>>     [2] https://gist.github.com/sharafian/df7a4b7e2ff000248800b113f0
>> 6f549a <https://gist.github.com/sharafian/df7a4b7e2ff000248800b113f
>> 06f549a>
>>
>>     On Tue, Feb 7, 2017 at 6:31 PM Tony Arcieri <tony@chain.com <mailto:
>> tony@chain.com>> wrote:
>>
>>         On Mon, Jan 30, 2017 at 7:49 AM, David Nicol <
>> davidnicol@gmail.com <mailto:davidnicol@gmail.com>> 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.
>>
>>
>>         There's an alternative to canonicalization: content-aware hashing
>> that's independent of the encoding.
>>
>>         Some examples are:
>>
>>           * Ben Laurie's objecthash: https://github.com/benlaurie/o
>> bjecthash <https://github.com/benlaurie/objecthash>
>>           * Peter Todd's proofmarshal: https://github.com/petertodd/p
>> ython-proofmarshal/blob/master/__init__.py <https://github.com/petertodd/
>> python-proofmarshal/blob/master/__init__.py>
>>
>>
>>
>
>
Received on Wednesday, 8 February 2017 07:00:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 February 2017 07:00:14 UTC