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

Re: Worldview conflicts on the purpose of DID documents

From: =Drummond Reed <drummond.reed@evernym.com>
Date: Wed, 13 Dec 2017 18:33:26 -0500
Message-ID: <CAAjunnaUgx1h2m-1Lf0f=Cz89Vewb-ybVCS=4HG00Uh_KyB4_g@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Credentials Community Group <public-credentials@w3.org>
On Wed, Dec 13, 2017 at 3:23 PM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On 13 December 2017 at 19:38, =Drummond Reed <drummond.reed@evernym.com>
> wrote:
>
>> 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.
>>
>
> The agent world view was quite a long sentence.  Could it be perhaps
> rephrased or broken into more than one sentence.
>

My apologies. Here's a slightly expanded description of the "agent
worldview" (which is an arbitrary name, BTW, not anyone's doctrine
anywhere):

   - Agents are software processes that perform interactions on behalf of
   their owners/controllers. They broadly fall into two categories:
      - *Edge agents* run at the edge of the network, on a user's device
      with the user interacting directly with the agent. Example: a mobile app
      that serves as an identity wallet. Edge agents are not expected to be
      always present on the network; they may come and go.
      - *Cloud agents* run in the cloud. Users do not interact with them
      directly, but through an edge agent, a web browser, or some
other edge app.
      They are typically always present on the network, similar to an email
      server or web server, and thus typically have a service endpoint at which
      they can be reached.
   - Agents don't have DIDs themselves, rather they represent the subject
   of the DID. So, if for example a DID identified a person, a service
   endpoint in the DID document can identify:
      - An agent (typically a cloud agent) for interacting with that person.
      - One more more cryptographic keys (or other cryptographic material
      as Joe points out) that can be used to to secure/verify
communications with
      the agent at that endpoint.

So in the agent worldview, what matters about a DID document is that it
represents a standard way to discovery the service endpoint(s) and
cryptographic key(s) needed to perform trusted interactions with the
subject of the DID via the subject's agent(s). Note that "interactions" is
unbounded, i.e., it's not just authentication, it may be encryption, key
negotiation, claims signing, etc. That's why key management is so important
to the agent worldview. (However I understand Joe's point, in a later
message, that keys are not as important in other worldviews. I'll reply to
Joe's message later today; must run into a meeting now).

=Drummond
Received on Wednesday, 13 December 2017 23:34:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:17 UTC