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

Worldview conflicts on the purpose of DID documents

From: =Drummond Reed <drummond.reed@evernym.com>
Date: Wed, 13 Dec 2017 13:38:37 -0500
Message-ID: <CAAjunnZh7fEo1y9W07whD_-ce5MsQ7wcEji8jjCYTtveVQQL-Q@mail.gmail.com>
To: Credentials Community Group <public-credentials@w3.org>
The Credentials Community Group has been holding a special set of calls to
drive towards closure of a next "Implementer’s Draft" of the DID spec
<https://w3c-ccg.github.io/did-spec/>. Three calls have been held so far,
and two more are currently planned (this Thursday and next Thursday at
10AM Pacific Time—see a separate message sent to the list for details of
each call).

After the last call, I started to see that some of the major sticking
points are due to what I call "worldview conflicts". These are
disagreements that usually surface as differences about details of a spec,
but where the real causes are rooted in different worldviews about
technology—different "big pictures" that different spec contributors are
working from/towards.

When this is the case, arguments that can go on for days/weeks/months about
the details can often be solved much faster by identifying and dealing with
the differences in the underlying worldviews.

So I wanted to start a thread just for discussion of these worldview
conflicts. I'll start by taking a stab at articulating the worldviews as I
understand them:

*THE RDF/JSON-LD WORLDVIEW*

In this worldview, DID documents are a standard way to describe a
well-known subgraph of a potentially very large RDF graph of data about a
subject. To quote this message from Dave Longley on a github DID issues
thread <https://github.com/w3c-ccg/did-spec/pull/36#issuecomment-351128922>:
"a DID document, is about establishing an independent entity and being able
to authenticate that certain activities/actions were performed by that
entity -- and to interact with that entity via services. This necessarily
includes specifying how that DID document can be changed." Linked Data
Signatures are also important in this worldview since it is the standard
way to sign JSON-LD documents.

*THE AGENT WORLDVIEW*

In this worldview, DID documents are about having an open, interoperable
way to discover and manage the cryptographic keys and service endpoints
necessary to bootstrap secure, verifiable connections, claims, and
interactions between agents acting on behalf of DID subjects.

*OBSERVATIONS*

First, obviously neither worldview is "wrong". They are just different
perspectives about the primary purpose of DID documents and the universes
into which they fit.

Second, in the RDF/JSON-LD worldview it is important to describe the data
using an RDF graph model using an ontology that can live alongside other
ontologies. In the agent worldview the primary importance is on
interoperability; it is not "anti-RDF", but it wants to avoid a dependence
on RDF in order to make it easy to consume/transform the metadata carried
by DID documents into other graph models and formats.

Thirdly, the two have different views of key management. In the
RDF/JSON-LD worldview the importance is on being able to authenticate an
interaction with the DID subject. In the agent worldview, a DID document is
the "public-face" (or "non-private-face") of all types of key management,
i.e., it is how a DID subject shares any type of key that needs to be
shared with another party to verify interactions, decrypt communications,
or do additional key negotiation.

*QUESTIONS*

First, it would be good to get feedback on these worldview descriptions
and observations from those who hold them. In other words, are the
descriptions accurate? Do the observations about them follow? Are there
other important points that are missing?

Secondly, once we have a picture of the differences in the worldviews, what
solutions to DID issues can we come up with that help reconcile these
differences and ideally work for both worldviews?
Received on Wednesday, 13 December 2017 18:39:04 UTC

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