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

On 9 December 2014 at 20:07, Dave Longley <dlongley@digitalbazaar.com>
wrote:

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

Verification:

1. remove @id

2. normalize

3. get sha256

4. compare hashes


>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
>