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

On 11 December 2014 at 21:17, Dave Longley <dlongley@digitalbazaar.com>
wrote:

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

+1 all makes sense

Just some thoughts:

My level of preference would be:

1. Meaningful hash
2. UUID
3. no identifier -- blank node

Note that ni:/// is simply the hash of *something* it can quite easily be
used at a UUID.

(3) is surprisingly common.  A helper function would achieve (2) and also
(1) drops out almost for free in perhaps the majority of cases.  Seems a
shame to throw out (2) because of some edge cases.

But I understand that you are the one that would need to support the code,
so edge cases increase the future work.  It's not too painful for me to
fork the library and add this function, and make it available as open
source.

When constructing a JSON LD data structure, I have no good ideas how to
give it an ID in a decentralized way, so this function will allow me to
work more effectively, I just thought others may need it too.

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