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

On 9 December 2014 at 05:43, David I. Lehn <dil@lehn.org> wrote:

> On Mon, Dec 8, 2014 at 9:24 PM, Melvin Carvalho
> <melvincarvalho@gmail.com> wrote:
> > On 8 December 2014 at 16:26, Dave Longley <dlongley@digitalbazaar.com>
> > wrote:
> >> On 12/08/2014 10:14 AM, Melvin Carvalho wrote:
> >> On 8 December 2014 at 16:06, Dave Longley <dlongley@digitalbazaar.com>
> >> wrote:
> >>> On 12/08/2014 04:40 AM, Melvin Carvalho wrote:
> >>> On 8 December 2014 at 04:31, Manu Sporny <msporny@digitalbazaar.com>
> >>> wrote:
> >>>> Digital Bazaar has just released a convenience library for creating
> and
> >>>> verifying JSON-LD Signatures in Javascript in the browser and in
> >>>> node.js:
> >>>>
> >>>> https://github.com/digitalbazaar/jsonld-signatures/
> >>>> ...
> >>> ...
> >>> Three things I'd love to see as convenience functions:
> >>>
> >>> 1. Normalize -- Done
>
> You are referring to the normalize() call in jsonld.js right?
>

yes


>
>
> >>> 2. Signing -- Done
>
> I'm pretty sure you are referring to the jsonld-signatures API right?
>

yes


>
>
> >>> 3. Hash content into ID, so that blank nodes can easily be replaced
> with
> >>> a URI (I'd suggest ni:///sha256;<base64urlhash>
> >>>
> >>> (3) would facilitate (2) more easily, imho, as part of a common 3 step
> >>> process
> >>>
>
> Did you want this hashing utility in the jsonld-signatures lib?  It
> doesn't seem like it has anything to do with signatures.  Seems like
> it should be in a new library but it might need to know jsonld.js
> internals.
>
>
> >>> What would the details of (3) be? What is the "content" that would be
> >>> hashed?
> >>
> >>
> >> What I usually do is hash the normalized form, which I think is possibly
> >> the most logical thing to do?
> >>
> >> So:
> >>
> >> if @id
> >>   return
> >> else
> >>   @id = sha256(normalized(json-ld))
> >>
> >>
> >> The blank node IDs would then be a part of the "content" you're hashing.
> >> The two step process would be:
> >>
> >> 1. Normalize the document (dataset) and hash (eg: sha256).
> >> 2. Replace the canonical blank node IDs from the document using the "ni"
> >> URI scheme and hash.
> >
> >
> > Yes!
> >
> >> After step #2, normalizing and hashing the document now produces a
> >> different hash,
> >
> > Correct
> >
> >> which seems to make the use of such a hash in the document IDs not all
> >> that useful,
> >
> > It's a hash of the content, not of ID+content. Hashing the ID before you
> > know it is kind of hard.
> >
> >>
> >> confusing even. Thoughts?
> >
> >
> > Yes, I can see that.  It is slightly confusing but as a utility function
> > very helpful?
> >
> > Not just for credentials or payments, for any data structure (JSON or
> > otherwise) without an ID. This might have billions or trillions of use
> > cases.  Naming is hard and everyone will have a strategy for it, but a
> neat
> > convenience function that will give you a UUID that's also a hash of the
> > content I think is useful.  This can allow developers to get up and
> running
> > more quickly when working with unnamed data.
> >
>
> Pardon the excessive quoting... I'm confused by much of this
> discussion and not sure where to start!
>
> Dave suggested running the current algorithms to get canonical blank
> nodes, then replacing them, yet then it is mentioned only the content
> is hashed?
>
> What is the intended purpose of these hash ids?  Globally unique blank
> node ids?  Globally unique content ids?  Content hashes will only be
> globally unique if they are hashing content that already includes some
> other globally unique id.  As an example, JSON-LD like {"foo":"bar"}
> that appears one or more times in one or more datasets would generate
> the same id hash each time right?  If the intent is to generate UUIDs,
> then it seems using RFC4122 UUID algorithms to generate blank node ids
> is the way to go.  If you want to use RFC6920 URIs, then maybe hash
> the RFC4122 data?
>

Identical content will produce an identical hash.


>
> In general, I thought the theory was that if you wanted data to have
> an id, you give it an id.  Content hashes are useful for many various
> reasons, but you need to make sure the use cases and algorithms handle
> hash uniqueness or non-uniqueness as appropriate.  I'd like to hear a
> bit more about what the real use cases are for this idea.
>

The idea is convenience and utility for developers.  From a generic JSON
data structure it would be possible to name, canonicalize and sign with a
key, arbitrary data, with or without an ID.


>
> Also, I'm not sure what this has to do with credentials. :-)
>
> -dave
>