Re: New JSON-LD digital signature library for Javascript (browsers and node.js)

On 12/08/2014 10:14 AM, Melvin Carvalho wrote:
>
>
> On 8 December 2014 at 16:06, Dave Longley <dlongley@digitalbazaar.com 
> <mailto:dlongley@digitalbazaar.com>> wrote:
>
>     On 12/08/2014 04:40 AM, Melvin Carvalho wrote:
>>
>>
>>     On 8 December 2014 at 04:31, Manu Sporny
>>     <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>> wrote:
>>
>>         Digital Bazaar has just released a convenience library for
>>         creating and
>>         verifying JSON-LD Signatures in Javascript in the browser and
>>         in node.js:
>>
>>         https://github.com/digitalbazaar/jsonld-signatures/
>>
>>         The package is in npm (and bower):
>>
>>         https://www.npmjs.org/package/jsonld-signatures
>>
>>         The software is released under a BSD license (free for use in
>>         both open
>>         source and proprietary systems).
>>
>>         If you're interested in what the digital signature creation
>>         process
>>         looks like, here it is:
>>
>>         https://github.com/digitalbazaar/jsonld-signatures/blob/master/lib/jsonld-signatures.js#L109
>>
>>         and the digital signature verification process:
>>
>>         https://github.com/digitalbazaar/jsonld-signatures/blob/master/lib/jsonld-signatures.js#L207
>>
>>
>>     Awesome!
>>
>>     I'm right it only works with RSA keys right now, e.g. not with
>>     bitcoin ECC?
>>
>>     Slight nit pick:  perhaps the graph signature 2012 URL could be a
>>     default option?
>>
>>     Three things I'd love to see as convenience functions:
>>
>>     1. Normalize -- Done
>>     2. Signing -- Done
>>     3. Hash content into ID, so that blank nodes can easily be
>>     replaced with a URI (I'd suggest ni:///sha256;<base64urlhash>
>>
>>     (3) would facilitate (2) more easily, imho, as part of a common 3
>>     step process
>>
>>     Thoughts / good idea / bad idea?
>
>     What would the details of (3) be? What is the "content" that would
>     be hashed?
>
>
> What I usually do is hash the normalized form, which I think is 
> possibly the most logical thing to do?
>
> So:
>
> if @id
>   return
> else
>   @id = sha256(normalized(json-ld))

The blank node IDs would then be a part of the "content" you're hashing. 
The two step process would be:

1. Normalize the document (dataset) and hash (eg: sha256).
2. Replace the canonical blank node IDs from the document using the "ni" 
URI scheme and hash.

After step #2, normalizing and hashing the document now produces a 
different hash, which seems to make the use of such a hash in the 
document IDs not all that useful, confusing even. Thoughts?

-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com