W3C home > Mailing lists > Public > public-credentials@w3.org > December 2017

Re: Worldview conflicts on the purpose of DID documents

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 14 Dec 2017 00:08:02 -0500
To: public-credentials@w3.org
Message-ID: <69f1c76f-94bc-d5d1-11e8-05d9b683d710@digitalbazaar.com>
On 12/13/2017 03:45 PM, Markus Sabadello wrote:
> I've been feeling for a while now that (for the reason of not 
> breaking basic web architecture), a DID should in principle be 
> resolvable to any RDF/JSON-LD document.

One could go further (like you do below) and say that you should be able
to content-negotiate on DID Documents (which Veres One supports in
theory now, and in practice as soon as we implement it, which will take
about a day... Dave Lehn, do we already have auto-conneg for stuff like
NQuads?).

> Saying that a DID document must [not] contain certain elements is 
> like saying that an HTTP URI must resolve to an HTML document that 
> contains a very specific HTML document structure.

Yep, we can't stop anyone from adding stuff to a DID Document.

> You could even go a step further and say that a DID could in theory 
> resolve to any MIME type (just like HTTP URIs).

Yep, and in the Veres One case we can easily support JSON, YAML, CBOR,
and any RDF syntax because of the design choice to use JSON-LD.

Now, whether or not that's useful to do is another discussion entirely. :P

> At the same time, yes we (mostly) invented DIDs for the purpose of 
> discovering associated keys and service endpoints for 
> agents/hubs/etc., and we need to define how that works.

+1

> So even though in principle DIDs should be based on a very broad 
> "worldview", we do want to define "hardened DID documents" (just
> like in theory you could define "hardened HTML documents" for certain
> uses of HTTP URIs).

I'd phrase this as: we need to define what parts of a DID Document are
required for interoperability.

We also need to understand that we can choose to have very little
interoperability (e.g. authentication only),  a little more interop
(e.g. authentication + services), or more (e.g. authentication +
services + path resolution), etc...

> I don't see a conflict here, the spec just needs to articulate this.

+1

> I disagree with Dave that DID documents "necessarily include 
> specifying how that DID document can be changed". This is a 
> requirement specifically for Veres One, and there's nothing wrong 
> with Veres One DID documents to include this information. None of
> the other DID methods need this, because they have their logic of
> "who can update the DID under what conditions" built into their
> specific method.

Yep, it's hard coded into the ledger in other DID Methods. Veres One is
declarative and ocap based. We thought others would want to do this, but
it's becoming clear now that some don't... so it sounds like this is an
aspect of interop that we're going to back off on in the coming
weeks/months. To be clear, Veres One will still take this approach (and
we need to figure it out as a community because Verifiable Credentials
will probably have this as a delegation option)... but again, I don't
think it's clear that all ledgers will allow DID Document updates to be
declarative.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The State of W3C Web Payments in 2017
http://manu.sporny.org/2017/w3c-web-payments/
Received on Thursday, 14 December 2017 05:08:30 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:46 UTC