Re: Worldview conflicts on the purpose of DID documents

On 12/14/2017 07:38 AM, Pelle Braendgaard wrote:
> Thanks Drummond for bringing this up.
> 
> This equates to some of the problems we from uPort have had with this
>  process.
> 
> We need to be better at differentiating between MUST and SHOULD. But
> I also think that things that are completely out of the scope for the
> core functionality should not even be in the core spec.
> 
> Our use case is basically exactly the same as Drummond's agent use
> case.
> 
> I think one of the big reasons for the different world views is also
> in our core philosophies. the JSON-LD/RDF world seems to be so
> focused still on the HTTP world (aka centralized world). HTTP and
> hyperlinking is at it's core so it's very hard to imagine a world
> where that is no longer important. Those of us in the "agent" camp
> live in a post HTTP world. That doesn't mean we don't use HTTP
> occasionally as glue services for interacting with our respective
> blockchains or other decentralized storage mechanisms.

I think this is a misconception that may stem from the name of the world
view which may be unfortunate. I think one world view is "independent
entity centric" and the other is "key management and service centric".

In the first world view, what is important is the ability to:

1. Establish an independent entity.
2. Authenticate interactions or statements as being with or originating
with that entity.
3. Allow the entity the ability to say how their own information can be
modified.
4. Allow the entity the freedom (open world assumption) to express
information in their DID documents in an interoperable way such that
applications can make use of it and innovate at the edges.

 From this world view, keys are an important tool that enable the above
to happen, but key management is not the whole picture. The agents that
act in the system are the entities -- and establishing that they exist
(and exist independently of centralized systems) is core. This seems to
be the antithesis of what is suggested above.

Of course, the ability to link information and using a graph model does
not imply the use of HTTP. And, of course, HTTP is still a useful
technology and will continue to be far into the future, so having
bridges from the decentralized technologies we want to build back to
HTTP is important. But the first world view is actually primarily
concerned with establishing entities that are independent from that world.

> 
> At uPort we do have a graph view of the world but it is not at the
> core of what we do. The graph is built up through a combination of
> private off-chain data and public on-chain data. We use JSON-LD
> currently for a few things, IPFS and it's linked data concepts for
> others. But more importantly most of our statements need to be
> atomic, self contained and cryptographically signed in a way that is
> easily verified, stored and shared. The JSON-LD model does not work
> for this. Specifically for the reasons that Manu points out as
> benefits.
> 
> Basically we have 2 really important functions that we need of
> DID's:
> 
> - Resolve a public key from a DID so we can interoperate in verifying
>  credentials between implementers - Discovering where to send
> credentials or other information to reach the user.
> 
> Anything besides that I see as out of scope of the core DID 
> specification. That does not say that people can't turn these DID 
> documents in to full JSON-LD documents and put all sorts of 
> implementation specific details in there. Go at it. But either do it
> as DID method specific spec or as a separate spec. The reason that it
> is important to leave it out of the core spec is that a bunch of 
> implementation specific details complicate us telling the story of
> the benefit of DID to users and stake holders.
> 
> At uPort we need nothing else and will implement nothing else. If we
>  can't resolve a public key for a DID we can't interoperate with you,
>  regardless how clever your implementation.

I believe we need to do two things at once (and I think we can do this):

1. Enable participants like uPort to implement interoperable DID
documents that include only the minimal bits they are interested in.

2. Design DID documents such that they *enable* the use cases everyone
cares about.

This does not mean that we need *only* to provide for the lowest common
denominator. It means that we need to make it so that uPort need only
implement the lowest common denominator with no significant effort
beyond it. We may need to make a number of decisions that impact the
shape of our design on the basis of use cases that uPort does not care
about -- but that's ok, because it does not unduly burden uPort.


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

Received on Thursday, 14 December 2017 17:53:12 UTC