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: Dave Longley <dlongley@digitalbazaar.com>
Date: Tue, 09 Dec 2014 14:07:27 -0500
Message-ID: <5487486F.6050801@digitalbazaar.com>
To: public-credentials@w3.org
CC: Melvin Carvalho <melvincarvalho@gmail.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.

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. 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.

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?


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
Received on Tuesday, 9 December 2014 19:07:50 UTC

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