- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Tue, 9 Dec 2014 03:24:33 +0100
- To: Dave Longley <dlongley@digitalbazaar.com>
- Cc: W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAKaEYhLAr493VuC5EafJ00W58vGJTyL9B2KEuXR48+pS-vq7cA@mail.gmail.com>
On 8 December 2014 at 16:26, Dave Longley <dlongley@digitalbazaar.com> wrote: > On 12/08/2014 10:14 AM, Melvin Carvalho wrote: > > > > On 8 December 2014 at 16:06, Dave Longley <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> >> 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. > Yes! > > After step #2, normalizing and hashing the document now produces a > different hash, > Correct > which seems to make the use of such a hash in the document IDs not all > that useful, > It's a hash of the content, not of ID+content. Hashing the ID before you know it is kind of hard. > confusing even. Thoughts? > Yes, I can see that. It is slightly confusing but as a utility function very helpful? Not just for credentials or payments, for any data structure (JSON or otherwise) without an ID. This might have billions or trillions of use cases. Naming is hard and everyone will have a strategy for it, but a neat convenience function that will give you a UUID that's also a hash of the content I think is useful. This can allow developers to get up and running more quickly when working with unnamed data. Note: ni:/// (RFC 6920) is also an IETF standard that allows dereferencing via HTTP and the .well-known pattern, which is an extra advantage for anyone that wants to use that pattern too. Thoughts? > > -- > Dave Longley > CTO > Digital Bazaar, Inc.http://digitalbazaar.com > >
Received on Tuesday, 9 December 2014 02:25:02 UTC