W3C home > Mailing lists > Public > public-credentials@w3.org > December 2014

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

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Tue, 9 Dec 2014 21:55:09 +0100
Message-ID: <CAKaEYhLxsk-Mqnm3nnoB18sEStLEs7uobNXb4KdMRgtdFGNeUA@mail.gmail.com>
To: Dave Longley <dlongley@digitalbazaar.com>
Cc: W3C Credentials Community Group <public-credentials@w3.org>
On 9 December 2014 at 20:07, Dave Longley <dlongley@digitalbazaar.com>

> On 12/09/2014 03:48 AM, Melvin Carvalho wrote:
> >
> > Identical content will produce an identical hash.
> How would you reproduce the hash to verify this? Would you iterate over
> the document and remove any "ni" IDs, converting them to blank nodes?
> What if some of those were already "ni" IDs prior to running this
> proposed "ni" URI generation scheme? It seems there is insufficient
> information to reproduce the same steps required to produce the hash
> once the document has been modified. It seems you'd need to attach
> additional data to the document that indicates what the IDs of the nodes
> were prior to hashing -- which may defeat the purpose of the exercise.

Perhaps I should say, "For a given subject", identical content produces
identical hashes.

It's equivalent of taking the key/value pairs associated with a subject.

In sparql :

SELECT ?o ?p
    <ni:///hash>?o ?p .

> When I think about the details of this, it seems problematic. Perhaps
> all of the problems could be worked through to see the utility of it,
> but I'm not sold just yet. Keep in mind that "hash of the content"
> includes canonical blank node identifiers for all blank nodes in the
> document -- including the blank node you're about to rename in the next
> step of the process. That's what "content" means when you're talking
> about a graph; you've got to include the subject itself to talk about
> any triples.

sure, I dont see any problem cases, maybe when an object is a bnode perhaps

instead of content, would key/values be clearer?  That's what I mean by
content here.

> I don't see how you can do anything useful with the hash
> used in the "ni" URI without keeping track of the previous identifiers
> used in the graph. If the hash isn't useful, then perhaps a less complex
> approach for generating URIs would be preferred.

would love to know a less complex approach, I cant think of one

having an ID is useful on the web, ni is even more useful as it can be
dereferenced in a decentralized way

> So what I'm saying is that it seems this approach is only preferred if
> the hash is a useful piece of information (rather than opaque) -- it's
> something that can be easily regenerated and compared. How would that work?

Same way it's generated but remove the @id first.


1. remove @id

2. normalize

3. get sha256

4. compare hashes

> --
> Dave Longley
> Digital Bazaar, Inc.
Received on Tuesday, 9 December 2014 20:55:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:21 UTC