Add "hl" DID URL matrix parameter.

[peacekeeper]

This adds one concrete DID URL matrix parameter. See #189.

Description: A resource hash of the resource identified by the DID URL to add integrity
protection.

Example: did:example:1234;hl=zQmWvQxTqbG2Z9HPJgG57jjwR154cKhbtJenbyYTWkjgF3e

---

Preview | Diff

[msporny]

I don't understand why we need a matrix parameter for this. Why can't we just use an unmodified hashlink, like so:

did:example:1234?hl=zQmWvQxTqbG2Z9HPJgG57jjwR154cKhbtJenbyYTWkjgF3e

Note: Semicolon ; changes to question mark ?.

[peacekeeper]

I think what I imagined was that a hashlink matrix parameter would protect the DID Document, whereas a "regular" hashlink would protect the end result of the DID URL dereferencing process. In the following example:

did:example:abc123;service=hub;hl=xxxx/profile/mypic.jpg?width=300&height=100&hl=yyyy#fragment

The xxxx is the resource hash of the DID Document, whereas the yyyy is the resource hash of the mypic.jpg resource that the DID URL dereferences to.

Not sure if that's a valid use case or if it's important enough. I suppose you could argue that the DID Document needs no extra layer of protection, since the DID method itself must have a reliable resolution mechanism anyway.

[jandrieu]

To clarify your point, @peacekeeper I would suggest changing

A resource hash of the resource identified by the DID URL
to
A resource hash of the DID Document

Although... these URLs would be exceptionally brittle as DID Documents are designed to be changed without breaking the DID URL. If you hashlink the DID Document, you can no longer rotate keys, add service endoints, etc. without invalidating those DIDs.

[peacekeeper]

@jandrieu I agree with your points. Overall, I think the use of hashlinks with DIDs needs a bit more discussion to fully understand how they would work.

[jandrieu]

One particular use of hashlink that might be useful is for a hash of the DID Method specification. I could see this being used to resolve name collision and/or versioning issues.

It isn't short or pretty, but it would at least be definitive of WHICH method by that name is intended. DIDs aren't meant to be human readable, so maybe the extra hash isn't too big of a deal.

I've mentioned in w3c-ccg/did-wg-charter#32 that I could imagine a meta-method that might be useful to standardize within the working group. I was thinking of something like

 did:hash:zQmWvQxTqbG2Z9HPJgG57jjwR154cKhbtJenbyYTWkjgF3e:xkyt-fzzq-q4wq-f2d

But using a parameter, we could also do:

 did:btcr;mh=:zQmWvQxTqbG2Z9HPJgG57jjwR154cKhbtJenbyYTWkjgF3e:xkyt-fzzq-q4wq-f2d

Where the parameter mh means method hash...

[msporny]

The DID TF agreed to merge this during the 2019-08-01 meeting.