Re: DID Spec Hardening Proposal V3

Dave Longley writes:

> After TPAC, Chris and I talked quite a bit more about it and came up
> with a couple of rough ideas that I'll try to outline so we can get more
> people exploring them. Please jump in with anything I've left out or
> that you were thinking we'd do differently, Chris.
>
> First of all, we spoke about "path resolution" for DIDs in the context
> of retrieving documents over HTTP (or another protocol) that are rooted
> in a DID document (or, really, use a DID document like DNS).
>
> So, for example, how would one write a client to retrieve:
>
> did:ex:1234/http/foo/bar

[... snip ...]

> The same could be done for any protocol that supports path-based URLs
> (and potentially others) such as FTP, e.g.:
>
> did:ex:1234/ftp/foo/bar

This is one of a few options... noticably we're treating DIDs as a
replacement for DNS (+ SSL CAs) here (as we should) but awkwardly by
choosing did: as our uri scheme, we've dropped off the specification of
what protocol layer is part of the URI.  The solution suggested above
suggests that we'd use the first component of the path as effectively
the replacement.  That's one option (though it feels a bit kludgy,
though maybe all of these will)... maybe we should consider all of them:

 - did:ex:1234/http/foo/bar -- moving the protocol decision into the
   path, which is what we considered above.  Requires that clients be
   able to know how to do a mapping between what could be a wide range
   of protocols and this DID section of the path.  (Maybe that's true
   no matter what except for in the "mapping to an IP" direction below).

   What would it look like to log in via ssh via this route I wonder?

     # to log into this server via ssh
     ssh did:ex:1234/ssh
     # or, to copy a file locally
     scp did:ex:1234/ssh:/home/cwebber/foo/bar/baz.txt ./

 - did:ex:1234/foo/bar -- ie, skip "http" or whatever protocol... this
   suggestion would be that the service selection from a DID would be
   context-dependent.
   For instance, typing this in a browser's address bar would lead to
   always retrieving via http.  Again, to look at ssh:

     # to log into this server via ssh... a bit cleaner
     ssh did:ex:1234
     # or, to copy a file locally
     scp did:ex:1234:/home/cwebber/foo/bar/baz.txt ./

   However this may "confuse" applications that can download via
   multiple protocols:

     # Is this downloading over http or ftp?  Because wget supports
     # both.
     wget did:ex:1234/documents/happy_cat.jpg

 - http://did:ex:1234/documents/happy_cat.jpg -- prepend the scheme

   I'm not sure we can get buy-in to this, but one nice feature about it
   is that we could use DIDs as a more literal DNS, *or* use services
   the way we're doing them right now.  This looks nicest to me but
   sadly I think it won't work since we'll break a ton of URI parsers...
   after all, it *looks* like we have a colon in there for the port,
   but that doesn't make sense...

 - did:ex:1234:http/foo/bar -- Gosh I really like this route the best,
   but I'm not sure everyone else agrees.  (This would require that all
   of the DID methods reserve the : character and not use it in their
   idstring, but the good news is that that's already consistent with
   the specification.)  Let me make the following case:

    - It doesn't "kludge up" the path the way doing /http/foo/bar and
      /ftp/bar/baz does.  The path is the path and we have clean
      separation of DID URI components.  So effectively this is the
      "service" component of the DID URI.  Admittedly this is a
      significant change, but I think we're at the point in the spec
      where we could make it.

    - We could make the decision that this is the web and thus HTTP
      is the default, thus the same way that the port is optional
      (defaulting to 80 or 443 for http/https) in normal URIs.
      So did:ex:1234:http/foo/bar and did:ex:1234/foo/bar would be
      equivalent, but if you wanted to speak FTP, you'd need to do
      did:ex:1234:ftp/foo/bar

Having typed all that out and thus had a chance to better think about
it, it seems clear to me that the first and last options are the best,
but the last option seems like *really* the best to me. :)

How do people feel about the idea of this?  Here's a more formal
proposal:
 - services should be an optional component of a DID URI
 - but if left out, the service defaults to the HTTP service.

> Chris may have more to say about how this would be useful for addressing
> decentralized social media portability.

Well, we need a way for paths to be meaningfully retrievable.  If we
were going to use DIDs as a namespace for a user's objects on an
application participating in ActivityPub, we'd obviously have to know
how to retrieve them. :)

Received on Monday, 27 November 2017 18:47:01 UTC