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

Re: Worldview conflicts on the purpose of DID documents

From: Adrian Gropper <agropper@healthurl.com>
Date: Wed, 13 Dec 2017 23:18:41 -0500
Message-ID: <CANYRo8hrhh8LYm4AY9k7C+6uXTCswg+kmJeNZtbjN8ZUL+01vA@mail.gmail.com>
To: "=Drummond Reed" <drummond.reed@evernym.com>
Cc: Melvin Carvalho <melvincarvalho@gmail.com>, Credentials Community Group <public-credentials@w3.org>
Thanks, Drummond for capturing the agent worldview so clearly. It's the
core of HIE of One and any contribution we can make to this discussion. As
you point out, it's all about delegation. As a result of this delegation
focus, it also incorporates the object capabilities approach to security
and privacy.

In the agent worldview, identity is primarily interesting as it relates to
the agent as an authorization service that issues tokens with scopes that
are clear and reliably processed by clients and resource servers. In my
opinion, the self-sovereign authorization server is even more in need of
standardization than the self-sovereign identifier (DID) and associated DID
documents. This is because an authorization server can accept multiple
authentication and credentialing methods but it needs to interact with all
clients and resource servers in a relatively similar manner in order to
achieve critical mass of adoption. For example, complexity explodes if each
client must negotiate both authentication / credentialing and scopes with
both the agent and the resource server that has delegated control to the
agent.

The worldview dichotomy appears as we try to standardize the way scopes are
handled. OAuth and UMA on top of OAuth seem to have an allergy to linked
data protocols (I don't understand why). Meanwhile linked data could be a
solution to making scopes clear and reliable in UMA (but I have no
experience with RDF).

My gut tells me that the different world views would converge if we look at
the issue from a delegation and object capabilities perspective.

Adrian



On Wed, Dec 13, 2017 at 6:33 PM, =Drummond Reed <drummond.reed@evernym.com>
wrote:

> 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
>



-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/
Received on Thursday, 14 December 2017 04:19:08 UTC

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