Re: Worldview conflicts on the purpose of DID documents

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.

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.

Non public key authentication is an interesting point. If it can not be
used by another DID method to authenticate data without a third party I
don't see it as belonging in the core DID spec. Thus I see biometrics and
other such kinds of "key material" as being out of scope. If you as a
method implementer need this to authenticate a user in person, by all means
spec it out in a separate document and other people who need to implement
it can use it.

If we can fine the lowest common denominator and agree on that, then we can
get back to business and continue to innovate on our respective platforms.
More importantly we can actually start building this out and interoperate.
The only thing stopping us from implementing it, is the lack of agreement
on the core functionality.

I was not involved early in this process, but perhaps one of the problems
we have is that it is being done under the flag of the w3c? Most of us
implementing it (that I am aware of) are not doing so using web
technologies. Could we perhaps to the core DID spec and do the web
implementation specific work within w3c?

Pelle

On Thu, Dec 14, 2017 at 5:27 AM, =Drummond Reed <drummond.reed@evernym.com>
wrote:

> On Wed, Dec 13, 2017 at 10:45 PM, Daniel Hardman <
> daniel.hardman@evernym.com> wrote:
>
>> How is this difference in worldviews leading to specific difficulties?
>>
>
> Daniel, so far my sense is that the biggest difficulty the difference in
> worldviews has been leading to is *key management* and *key description*.
>
> With regard to key management, in the RDF/JSON-LD worldview (or what Manu
> calls the "Graph-based Data Model with an Open World Assumption"
> worldview), key management and description is secondary to authentication..
> As Dave has said, authentication is the first priority, and as Joe
> explains, there are other ways to do authentication, so cryptographic keys
> are just one type of "authentication material".
>
> In the agent worldview, key management and key description is paramount
> since that's what agents use to form cryptographic trust for all types of
> interactions. Authentication is just one usage of cryptographic trust. DID
> documents can be used to share the "public" parts of many different types of cryptographic
> keys (see Table 1 on page 31 of NIST 800-130
> <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-130.pdf> or
> sections 4.2 and 4.3 of RFC 7517
> <https://tools.ietf.org/html/rfc7517#section-4.3>), so providing this
> aspect of key management is a high priority.
>
> With regard to key description, in the "Graph-based Data Model with an
> Open World Assumption" worldview, the ideal (as I understand it) would be
> to describe each key using an RDF graph based on an ontology for key
> description.
>
> In the agent worldview, the goal would be to keep each key description as
> simple and universal as possible. Thus the "hardening" proposal of using
> just three standard properties—id, type, and value— to describe any key.
> The type value is a URI (or JSON-LD name) that represents a unique (and
> hopefully recommended) combination of all properties of a key together
> with the purpose or usage for which it is designed.
>
> I hope this helps. The discussion has already been helpful to me. I'd
> like to reply to Markus', Joe's, and Manu's replies but must get sleep now
> to be ready for the next DID Spec Closure call at 10AM PT tomorrow. For
> anyone who is interested, we'll continue the discussion live there.
>
> =Drummond
>
>
>>
>> On Thu, Dec 14, 2017 at 12:08 AM, =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.
>>>
>>> *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?
>>>
>>
>>
>
>


-- 
*Pelle Brændgaard // uPort Engineering Lead*
pelle.braendgaard@consensys.net
49 Bogart St, Suite 22, Brooklyn NY 11206
Web <https://consensys.net/> | Twitter <https://twitter.com/ConsenSys> |
Facebook <https://www.facebook.com/consensussystems> | Linkedin
<https://www.linkedin.com/company/consensus-systems-consensys-> | Newsletter
<http://consensys.us11.list-manage.com/subscribe?u=947c9b18fc27e0b00fc2ad055&id=257df01285&utm_content=buffer1ce12&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer>