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

On 12/09/2014 05:37 PM, Melvin Carvalho wrote:
> 
> 
> On 9 December 2014 at 22:44, Dave Longley <dlongley@digitalbazaar.com
> <mailto:dlongley@digitalbazaar.com>> wrote:
> 
>     On 12/09/2014 03:55 PM, Melvin Carvalho wrote:
>     >
>     >
>     > sure, I dont see any problem cases, maybe when an object is a bnode perhaps
> 
>     Actually, this is exactly the case I'm thinking of. I don't see how this
>     works when there are other blank nodes involved; how do you assign them
>     names? (It's repeat of the problem that is solved by the normalization
>     algorithm itself).
> 
> 
> Ah yes this is a complex case.  Does the object bnode have a consistent
> name when the graph is normalized?  Or is it problematic when the child
> bnode makes a cycle back to the parent?

The normalization algorithm guarantees a consistent name for all bnodes.
If you subsequently change some names (to URIs), then others may be
given different names when renormalized. So, in this case, you'd need to
know which bnodes were renamed prior to running the normalization
algorithm again (in order to later reproduce the hash and confirm it).

> 
> I had assumed that the hashing problem was no more difficult than
> normalization, and if normalization is solved, hashing may drop out for
> free.

Well, it's certainly free to hash after normalization. The tricky part
is going back in and changing the data ... by using a hash that wouldn't
be reproducible in all cases without keeping track of extra information.

> 
> If there's some complex cases I may not have considered, I can see why
> that would be an issue, though I could not initially think of a problem
> example.

A simple example is just a blank node in the object position that has
other statements about it:

_:b0 <http://example.com/foo> _:b1 .
_:b1 <http://example.com/bar> "baz"

If you normalize those statements independently to generate
"content-based" ni-hash URIs for each blank node, then you've got to
keep track of the fact that _:b1 changed so you can pass that
information back in when trying to replicate the hash later for whatever
URI was assigned to _:b0.

> 
> Sure I guess it's not an issue for me as I try to avoid bnodes.  It's
> possible to throw an error in that case.

It seems somewhat hackish to throw an error just because a bnode was
found in the object position. It wouldn't feel like a full solution, I
don't think, to people interested in using it.

> 
> Can understand if this not considered useful upstream, I could implement
> it in a fork, or other library, I suppose.

I like the concept of tying a blank node ID to a hash that's meaningful.
So I'd like it to be workable but I just don't see it yet. I do think it
should probably go in a separate library (separate from
jsonld-signatures anyway). I'd support seeing it as either a utility in
jsonld.js or separate jsonld tools lib -- so long as the issues are
sorted out.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Thursday, 11 December 2014 20:17:56 UTC