W3C home > Mailing lists > Public > public-interledger@w3.org > March 2016

Re: Note on JSON signing

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Fri, 11 Mar 2016 21:12:27 +0100
Message-ID: <CAKaEYh+aHqsZqeunRMgEWHngSTj3BfHF20VLPjRYSBz1Q9joZg@mail.gmail.com>
To: Stefan Thomas <stefan@ripple.com>
Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, Interledger Community Group <public-interledger@w3.org>
On 11 March 2016 at 20:50, Stefan Thomas <stefan@ripple.com> wrote:

> We need to sign JSON objects in a few places in the ledger and connector
> level APIs. After evaluating the options, we concluded:
> Secure Messaging [1] depends on RDF Graph Normalization which is a fairly
> complex process. We don't think it's a good idea to have a signature
> standard have a complex dependency like that, despite the benefits. The
> spec also isn't very widely used.

What do you mean by "complex".  Isnt it just the normalize() function.

I use this, and found it pretty easy.  I intend to use it for inter ledger
work too.

Having reviewed your code in the past, which is in general high quality and
advanced (particularly 5 bells stuff), im surprised that you found this
piece challenging.  Did I miss something?

> JSON Web Signatures (JWS) [2] normally contain the data they is signing.
> So our objects would get bloated by a bunch of base64-encoded redundant
> JSON - incredibly wasteful and ugly in our case. It was designed for
> signing tokens, not objects in an API, so it really isn't meant for our use
> case. Since transfers could get large with nesting, this is a dealbreaker.
> We can deviate from standard JWS and just provide the signature by itself.
> JWS library usually support this way of using it. So that's nice, but now
> the standard doesn't specify how to canonicalize the JSON, what to call the
> signature header field, what to call the signature field, where those
> fields should be added in relation to the object being signed.
> Fortunately, somebody else has already run into the exact same issue.


> JCS [3] is designed for our use case exactly. It is building very closely
> on JWS in the sense that it would be trivial to extend a JWS library with
> JCS support. In most cases you'll even be able to use a JWS library to
> verify and generate JCS signatures with minimal glue.
> For these reasons, we plan to use JCS in the reference implementation for
> now. Curious to hear everyone's input, the final decision on what the
> long-term API will be is still open.

Not sure I'll support this unless there's a large benefit in terms of user
base.  Good food for thought though.

> [1] https://web-payments.org/specs/source/secure-messaging/
> [2] https://tools.ietf.org/html/rfc7515
> [3] https://cyberphone.github.io/openkeystore/resources/docs/jcs.html
Received on Friday, 11 March 2016 20:12:56 UTC

This archive was generated by hypermail 2.3.1 : Friday, 11 March 2016 20:12:57 UTC