Re: A simpler approach to DID services and content-addressing

Magnet URIs, though not standardized, can accomplish this an a general
way through composition of multiple URIs, and have been used in this way
for some time.

magnet:
  ?as=did:example:12345678:path:blog:/2019-03-01/lunch-in-barcelona
  &xt=urn:sha256:<hash>

Where "as" stands for "acceptable source" (someplace that might change,
but where you can find it) and "xt" stands for "eXactTopic" (content
addressed hash, which won't). 

Separation of concerns via composition.

https://en.wikipedia.org/wiki/Magnet_URI_scheme

Manu Sporny writes:

> Apologies for missing the last DID spec call, some of us thought it had
> been cancelled due to KNOW2019 and travel. I was reading the minutes
> from the last meeting[1] and was happy to see two use cases identified
> as driving factors for the DID URI scheme syntax (aka, ABNF) discussion.
> I'm also attempting to build on the work that Drummond and Ken did
> during RWoT8 (so you two may see some stuff that's familiar in here).
>
> Let me try and summarize the use cases that seem to be driving the DID
> URI scheme syntax:
>
> 1. Pat wants to publish blogging content in a way where they can switch
>    service providers, but the relative URLs don't change. For example,
>    <PORTABLE_SERVICE_PROVIDER_URL>/2019-03-01/lunch-in-barcelona
>    ... which would be transformed to:
>    <CURRENT_SERVICE_PROVIDER_URL>/2019-03-01/lunch-in-barcelona
>
> 2. Yael wants to publish content in a way that ensures the content
>    integrity of the content. For example,
>    <CONTENT_URL><SEPARATOR><CONTENT_INTEGRITY_CHECK>
>    ... which would be transformed to:
>    <PROTECTED_CONTENT_URL> (which returns tamper-evident data)
>
> Now, let's narrow that down to the specification we're talking about,
> which is the DID Specification. The pattern would change to something like:
>
> <START_OF_DID><MAGIC><PATH>
>
> and
>
> <START_OF_DID><MAGIC><CONTENT_INTEGRITY_CHECK>
>
> Much of this discussion has been around the <MAGIC> bit above. We know
> what we want at the end, but there are many things that could go in the
> middle. I should also note that these are two totally different use
> cases and the group is probably thrashing because you're attempting to
> solve both of them simultaneously. In this case, though, I think there
> is at least one simple answer that doesn't require overly-complicated
> microsyntaxes. So, here goes:
>
> Use a colon-delimited keyword that you tack on to the end of a "bare DID".
>
> That's it. Here's how it looks in practice for the two use cases above.
>
> For the "Portable URL":
>
> did:example:12345678:path:blog:/2019-03-01/lunch-in-barcelona
>
> ... which would be transformed to:
>
> https://example.org/2019-03-01/lunch-in-barcelona
>
> For the "DID with Content-addressing" (example assumes a Sovrin-like
> requirement to get a content addressed schema):
>
> did:example:schema:hl:z3aq31uzgnZBuWNzUB
>
> ... which would enable you to fetch things from that particular DID
> Registry using content-based addressing.
>
> The general matching pattern for the syntaxes are:
>
> For the "Portable URL" use case:
>
> did:<did-method>:<method-specific-id>:path:<service-id>:<service-path>
>
> and for the "DID with Content-addressing" use case:
>
> did:<did-method>:<method-specific-id>:<hashlink>
>
> Note how the use cases are handled with things that you put *at the end*
> of the DID URI syntax? This is on purpose for two reasons:
>
> 1. It ensures that DID Method authors have very broad control over what
>    happens in <method-specific-id>, and
> 2. It enables decentralized innovation to occur while providing a clear
>    adoption path into the core DID spec. (I think this is a nuance that
>    many people might not get right now, but that's ok).
>
> Here are two potential resolution algorithms for both use cases:
>
> For the "Portable URL" use case:
>
> 1. Search for ":path:" from the end of the DID URL.
> 2. Split on the first two colons, you should have a 3-tuple:
>    ("path", service-id, service-path).
> 3. Search the DID Document "service" property for a service
>    with an "id" ending in "#<service-id" and save this value
>    as "service-prefix".
> 4. Concatenate "service-prefix" with "service-path" and return
>    this value.
>
> For the "DID with Content-addressing" use case:
>
> 1. Search for ":hl:" from the end of the DID URL.
> 2. Split on the first colon, you should have a 2-tuple:
>    ("hl", hashlink-value).
> 3. Dereference the DID URL and cryptographically hash
>    the content.
> 4. Compare the hash of the content against the value
>    of the hashlink. If the hashes match, the content is
>    secure.
>
> I believe the proposal above addresses all of the use cases raised by
> Evernym and Sovrin. I also think it's compatible with Veres One and
> IPFS-based DID Methods. The benefits of this approach are:
>
> 1. It ensures that DID Method authors have very broad control over what
>    happens in their <method-specific-id>, and
> 2. It enables decentralized innovation to occur for these sorts of
>    DID URI syntax extensions while providing a clear adoption path into
>    the core DID spec, and
> 3. It doesn't require microsyntaxes more than what we have in the
>    specification right now, and
> 4. The grammar parsing rules are extremely simple, and
> 5. It only requires one type of separator character for the DID URI
>    syntax, the ":" character.
>
> What did I miss? Why doesn't this work? I checked this against all the
> current use cases (but did not elaborate on every one as this email is
> long enough as it is). Would this work for your use case?
>
> -- manu
>
> [1]https://raw.githubusercontent.com/w3c-ccg/meetings/gh-pages/2019-03-28-did-spec/2019-03-28-irc.log
>
> [2]https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/draft-documents/did-spec-refinement.md#feature-refinement

Received on Wednesday, 17 April 2019 20:33:12 UTC