Re: DID Spec Hardening Proposal V3

On 11/25/2017 05:31 PM, =Drummond Reed wrote:
> Melvin, I like the idea of sites being able to publish a DID via their 
> HTTP(S) URLs at /.well-known/did/ . It would be easy for a DID resolver 
> to verify that against a DID document if we established a standard 
> service endpoint for verifying the association of a website URL with a DID.
> 
> Thoughts from others?

Chris Webber, Kim, Nathan, Joe, myself, and some others chatted a bit at
TPAC about making better use of DIDs as URLs. This includes resolution
over protocols such as HTTP.

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

Our proposal is essentially that the client would:

1. Retrieve the DID document identified by "did:ex:1234" according to
the DID method (more on this later).
2. Search its services for an HTTP service (yielding an IP address or a
domain or root URL).
3. Retrieve over HTTP: http://<the IP or domain>/foo/bar

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

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

Next, we talked about how one of the original intents behind DID
resolution was to play nicely with HTTP. The first implementation of
DIDs (at authorization.io) used HTTP as its primary retrieval mechanism.
If every DID method supported the retrieval of DID documents via HTTP,
we would get excellent interoperability at little cost (on the client
side). In other words, it would be much easier and simpler to write a
client that could resolve DIDs from a variety of different sources
(e.g. ledgers).

So the question is -- how can this be achieved and can it be done easily
enough with each DID method so that applications can all benefit from
this interoperability? Veres One is designed to support HTTP-retrieval
of DID documents, but what about other methods? Can it work generally?

Suppose that a DID resolver had a set of rules for every DID method it
supported that it could use to determine an IP address or domain to hit
to retrieve a DID document. For example, when a client is given the URL:

did:ex:1234

1. The client chooses an IP address (or domain) from a set of trusted
seed peers for the `ex` method, similar to choosing a primary or
secondary DNS server.
2. The client performs an HTTP request for:

https://<chosen IP>/.well-known/did/did:ex:1234

Or perhaps:

https://<chosen IP>/.well-known/did/1234

Or perhaps:

https://<chosen IP>/did:ex:1234

(The exact details of how to construct the HTTP URL TBD).

3. The peer returns the DID document, optionally containing appropriate
proofs therein. If no proofs are available or possible (for whatever
reason), the client may use the network perspectives approach and
request the same DID from multiple peers and compare.

In order for this to work, nodes participating in whatever ledger or
data source that is associated with a DID method must respond to HTTP
requests (or there could be a secondary resolver network for the DID
method that performs this function). For example, for BTCR, bitcoin
nodes could listen on port 80 (or 443) for HTTP requests and respond
with DID documents constructed from their view of the blockchain.

If every DID method supported this method of retrieval, DID resolvers
would become vastly more simple, interop would receive a significant
boost, and application developers could more easily embed these smaller
DID resolvers and focus on writing applications. Also, if we combine
this approach with the path resolution approach above, a DID resolver
that worked across all DID methods could be entirely implemented using
only HTTP for all HTTP-based service requests.

Note that there may also be some economic opportunities for trusted
resolution services that could arise from this model.

Anyway, I've been meaning to send some of these ideas out post-TPAC and
figured this thread was a good opportunity.


> 
> On Thu, Nov 23, 2017 at 12:48 PM, Melvin Carvalho 
> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
> 
> 
> 
>     On 22 November 2017 at 09:53, =Drummond Reed
>     <drummond.reed@evernym.com <mailto:drummond.reed@evernym.com>> wrote:
> 
>         For those W3C Credentials Community Group members who are not
>         taking the Wednesday before Thanksgiving off and would like to
>         attend tomorrow's special DID Spec Closure Call #1, here is the
>         updated DID Spec Hardening Proposal
>         <https://docs.google.com/document/d/1je9Bnhe-1tLgP1bfCSUjvbQ_qllwCz042aGncWX7Uio/edit?usp=sharing>
>         (called V3 because the proposers have iterated it twice based on
>         the feedback received from the first proposal).
> 
>         Reviewing this and contrasting it with the current Working Draft
>         (Decentralized Identifiers V0.7) will be the main topic of
>         tomorrow's call (10AM Pacific Time/1PM Eastern Time—see the
>         invitation emails earlier on the mailing list).
> 
> 
>     Thanks for sharing this.
> 
>     I noticed that the http URL where you can dereference the did is in
>     a number of places e.g. .identity or the root
> 
>     It would be easier to create a global web of reputation for
>     indexers, software and libraries if this was in a relatively
>     consistent place
> 
>     Typically, one would use the /.well-known/ pattern similar to
>     /.well-known/ni/ used in RFC 6920 it may be possible to use
>     /.well-kwown/did/
> 
>     If that's considered too restrictive perhaps it could be an example
>     or an opt in and / or use the rel=canonical pattern if it occurs in
>     more than one place
> 
>     I could picture this eco system getting quickly off the ground it it
>     were easy to create reverse indexes and offer services to everyone
>     consuming did's
> 
>     Thoughts?
> 
> 
>         =Drummond
> 
> 
> 


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Monday, 27 November 2017 16:16:47 UTC