Re: Adopting the Hashlink spec as a work item?

On Tue, 1 Jan 2019 at 22:38, Manu Sporny <msporny@digitalbazaar.com> wrote:

> Hi all (bcc: W3C JSON-LD WG, VCWG, and Protocol Labs Research Division),
>
> I promise that this is the last one for today. :)
>
> This email is about the Hashlink specification, which is intended to be
> a way to enforce that the content at a given hyperlink has not changed
> since it was published.
>
> The specification is intended to be a joint work product of the W3C
> Digital Verification Community Group, JSON-LD WG (unofficial), VCWG
> (unofficial), and the W3C Credentials Community Group. The CCG needs to
> decide if it's adopting this specification as a Work Item.
>
> Ok, so what's the problem and why do we care?
>
> We do the following things in this community:
>
>  * Link to JSON-LD Contexts
>  * Link to ZKP Schemas
>  * Link to evidence from Verifiable Credentials
>  * Link to external data from DID Documents
>
> ... and we have no way to tell if the content at the end of that link
> has changed since the Verifiable Credential was issued, or the DID
> Document was created.
>
>
> In the best case, verification of the cryptographic signature fails
> (because the content at the end of the link changed). In the average
> case, the signature doesn't fail, and we use data that may have been
> modified. In the worst case, the data was modified by an attacker and
> really bad things happen (like a developer being sloppy with how they
> use JSON-LD Contexts in a financial system and the source/destination
> fields being flipped in a financial transaction). There are mitigations
> for all of these issues, but they require the developer to be aware of
> the problem in the first place.
>
> What would be great is if we could trust that when we use a hyperlink in
> our systems (like a Verifiable Credential or a DID Document), and
> digitally sign that hyperlink, that we're also signing the content at
> the hyperlink. That's what the hashlink specification enables us to do.
>
> Here's a simple example for the JSON-LD Context for the current DID
> Spec. Here's the current link:
>
> https://w3id.org/did/v0.11
>
> You have no idea if the version you retrieved and the version I
> retrieved are the same. Now, here's what it looks like when we secure it
> with a "Legacy URL" Hashlink (blake2b 8 byte multihash + base58btc
> multibase):
>
> https://w3id.org/did/v0.11?hl=z3aq31uzgnZBuWNzUB
>
> Now we both know that the version we download is the same (because of
> the little bit at the end starting with "hl=", which stands for
> Hashlink). Here's what it looks like as a (non-legacy) Hashlink URL:
>
> hl:z3aq31uzgnZBuWNzUB:zpr1Xd34f3NYqfr1yMzb6TBCrWWrvJeGVRJGsUMMyVWXS8
>
> Yes, that looks awful, but there are a number of redeeming
> characteristics with the second form. The first is that the latter value
> is optional -- you can discard everything after the second colon and
> it's still a valid Hashlink URL. All you really need is
> "hl:z3aq31uzgnZBuWNzUB" and you can get the data from anywhere else
> (like different URLs, a local cache, etc.) and still thwart the attacks
> listed above.
>
> The other nice thing about Hashlink URLs, and this is the really
> exciting bit, is that you can create multi-sourced hashlinks that span
> completely different network architectures. Let's say that you had
> information that you really wanted to make sure didn't disappear (like
> the DID JSON-LD Context above), and you publish it at the following
> locations:
>
> https://w3id.org/did/v0.11
>
> magnet:?xt=urn:btih:73C59D931B7E0C089C031D6CFE0D16AE
>
> ipfs://ipfs/QmR7W4GQUFWDPMVrQfmNE8xJC6LoVAyaWeRnDp4gS9/did-v0.11
>
> onion://pq6kufupl4mc43g2/didv0.11
>
> The Hashlink URL would be really long, something like this:
>
> hl:z3aq31uzgnZBuWNzUB:zeGVRWXS8TakFeJueF2bim3PaaDqbtqjkpxUc8ETS
> WXe6dQLWXQWvqiUdw8TJrncx3uKhwfc88MtM5xZbR27FhVRUKv9ogekamVtdE3U
> bXnXpMRT1AseCtoBUt1NE8x2SsnJxGfiZN45VVSCp6jh4dgcufL16tWrHREiSYE
> SEGP1J75yXCvAdvKPr7nb5aY
>
> ... but the Hashlink URL above 1) ensures the integrity of the thing
> you're linking to, and 2) still works if 3 out of the 4 networks listed
> above failed. To put it another way, the link above could survive (for
> example) the failure of the Web, BitTorrent, and Tor.
>
> This approach also solves the following problems that other communities
> in our orbit are having by:
>
> * JSON-LD WG: Enabling backwards-compatible content integrity for JSON-
>         LD Contexts.
> * JSON-LD WG: Enabling non-Web-based, multi-sourced, compact, content
>         integrity for JSON-LD Contexts.
> * Sovrin: Enabling content integrity protected blockchain-based ZKP
>         Schemas to be hosted on the Sovrin ledger (and Web-based
>         locations) and referenced from Verifiable Credentials.
> * IPFS: Enable organizations to dip their toes into IPFS as a "backup
>         mechanism" w/o having to fully commit to jumping in with both
>         feet.
> * Verifiable Credentials WG: All the JSON-LD benefits above and the
>         ability to digitally sign content integrity protected
>         hyperlinks to evidence, terms of use, and any other information
>         linked to from a Verifiable Credential.
> * Credentials CG: Include links to data from DID Documents where the
>         content at the links are secured by the cryptography of the
>         ledger.
>
> The specification is 9 pages long and can be found here:
>
> https://tools.ietf.org/html/draft-sporny-hashlink-02
>
> This email is a request to the CCG Chairs to add this to the next
> meeting Agenda and for the CCG and adopt it as a work item.
>

+1 looks like an interesting initiative

Wouldn't one way to mitigate this to be to store the context inline?  That
is what happens in turtle @prefix command.

If I was going to implement this suite in solid I'd probably use turtle,
which has this advantage.  (I think this work wants to be compatible with
turtle, yes?)

Does solving the use case of 3 different places for the context go away, if
you put the context inline?  Or are there other places that hi: can be used?


>
> -- manu
>
> PS: For those wondering "Why not Magnet URIs, ni:/// URIs, or Resource
>     Integrity Proofs?", there is a very short explanation here
>     https://github.com/w3c-dvcg/hashlink#readme that I'm happy to
>     elaborate upon if needed.
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>
>