RE: what do DIDs identify?

Thank you Daniel!  …that’s the perfect lead-in to the second level of the DID ARM… this Application Architecture Layer is the one that feeds upward to support the Business Architecture Layer in the previous email…

A key “thing” that is missing from the draft DID spec is the formal recognition of the DID Entity.  It is referred to in many, many places as lower-case “entity” but never called out, named, and defined.  I’ve done this in the diagram below as well as in the Principles that follow.

[cid:image002.jpg@01D4A1FA.40DF02C0]

Here’s the Application Architecture Layer principles...  NOTE! This is a different layer is the standard (enterprise) architecture model.

1.       A DID Document is a JSON-LD serialization of a DID Entity.
2.      A DID Entity is the in-memory, application-specific object that represents a de-serialized DID Document.
3.      A DID Entity is what application developers work with (program against) at the Application Architecture level of an app.
4.      DID Entities have a set of attributes such as the following:
§  id (DID)
§  service (endpoints)
§  authentication
§  publicKey
§  @context
§  etc.
5.       “id (DID)” exists as an attribute of a DID Entity (and by implication, as an attribute of DID Document, the JSON-LD serialization of the corresponding DID Entity).
6.      The “id (DID)” attribute is given the nickname “DID” (aka Decentralized Identifier) for convenience; but more importantly, to clarify what a DID specifically refers to (as well as to clarify what the term DID specifically does not refer to).  “DID” should only be used to refer to the “id (DID)” attribute of a DID Entity (or DID Document).
7.       DIDs are used to index, find, and retrieve DID Documents from the Technology/Infrastructure Architecture layer.
8.      DID Documents represent the primary object type that is exchanged between the Application Architecture layer and the Technology/Infrastructure layer.
Scan https://hyperonomy.com/2018/12/21/decentralized-identifiers-dids-architecture-reference-model-arm/

Best regards,
Michael

From: Daniel Hardman <daniel.hardman@evernym.com>
Sent: January 1, 2019 5:36 PM
To: Michael Herman (Parallelspace) <mwherman@parallelspace.net>
Cc: W3C Credentials CG (Public List) <public-credentials@w3.org>
Subject: Re: what do DIDs identify?

Michael:

I think what you're laying out here does describe my issue with pretty good overlap. And of course you were one of the bright minds that I spent time learning from in Basel...

With respect to the notion that a DID is just a character string: I agree with you quite strongly. However, there is an *association* between the string and certain semantics, *by definition*. This association is reflected in rules about how DIDs can be created. The semantic assumptions are so strong sometimes that they leak into our verbiage in ways we don't strictly intend. If my verbiage had such leakage, I apologize. My email was about teasing out different layers of these assumptions, because I don't think they're monolithic.

I do disagree with one aspect of your characterization: I don't think the distinction between Actor and Thing is tenable. CF the entity hierarchy in Sovrin's V1 Trust Framework; it's described here: https://github.com/hyperledger/indy-hipe/tree/master/text/0014-ssi-notation#entities. The key insight is that what distinguishes People and Organizations from Things is not whether they are capable of action (including independent action, even)--but whether they are the sort of thing that can be held legally responsible for its actions.

A self-driving car is an actor; it's just one that is owned and operated by another actor. You could imagine an AI released into the wild with no controller (e.g., I instruct an AI to rotate its keys so I can never wrest control back); it would still be a thing, but it would also be an actor.


On Tue, Jan 1, 2019 at 5:25 PM Michael Herman (Parallelspace) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>> wrote:

  1.  RE: Such an identifier could be called an "uncontrolled DID", for example. And DIDs that make the strong assumption about control could be called "DIDs" for short, or "controlled DIDs" when clarity is needed. Or we could pick other adjective pairs.

This statement implies that a DID is a “something” …that is, a ID is something that is controlled/uncontrolled …it’s not  …it’s just a character-string identifier.  I think the referenced statement is trying to project high-level behaviour onto what is essentially a character-string behaviour.  It’s similar to the remarks I heard over and over again in Basel: e.g. “A DID can have a publicKey”.  It simply can’t …it’s only a character string.  Ditto for any higher-level adjectives/behaviours.

Scan https://hyperonomy.com/2018/12/21/decentralized-identifiers-dids-architecture-reference-model-arm/




  1.  RE: Or we could say that "DID" should only be used for the form of identifier that has strong control semantics, and that whatever the other thing is, it shouldn't be a "DID".

See above.  A DID is only a character-string identifier.

@Daniel: The root problem is an architectural terminology problem:  People insist on projecting all of the different layers of architectural functionality onto this poor character string. …it’s not fair :-)

Scan https://hyperonomy.com/2018/12/21/decentralized-identifiers-dids-architecture-reference-model-arm/


Best regards,
Michael Herman (Toronto/Calgary/Seattle)

From: Daniel Hardman <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>>
Sent: January 1, 2019 4:39 PM
To: W3C Credentials CG (Public List) <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: what do DIDs identify?

At the recent Hyperledger Global Forum in Switzerland, I had some discussions about the semantics of DIDs, and I feel like I observed a deep divide in community understanding about their intent. This causes periodic surprises and frustrations, including some that came up on the recent thread with subject "Ideas about DID explanation."

I'm going to try to contrast two divergent mental models. In reality they may not be so far apart. But I think until we see their divergence clearly, we may continue to experience mental friction when we least expect it.

1. DIDs are inherently about SSI
An inconsistently articulated but very strong assumption in this worldview is that a DID is an identifier controlled for the purpose of interaction. People, organizations, and IoT things can be behind the identifier because they are the sorts of entities for which interaction is imaginable-- but notice the "IoT" qualifier on "things": inert things cannot be DID referents. This worldview is nicely articulated by various statements in the the DID Primer and the DID Spec, such as this one: "The purpose of the DID document is to describe the public keys, authentication protocols, and service endpoints necessary to bootstrap cryptographically-verifiable interactions with the identified entity."

2. DIDs are inherently about decentralization, and SSI is just one use case
Proponents of this worldview might point to the name ("DID" = "Decentralized Identifier", not "SSI Identfier" or "Controlled Identifier") and say, "Of course we need decentralization for SSI. But we need it for other reasons, too. We should be using DIDs for lots of other stuff."

What other stuff? Well, the use cases I heard in Switzerland are pretty similar to the ones I would give for uuids: "I want a DID for every asteroid NASA discovers" or "I want a DID for {Mount Everest | each species that biologists add to the Linnaean taxonomy | each database record | flows in my ERP system | etc}". What makes these different from the classic DID use cases is that the identified item is not imagined to interact in the ways that we expect as we usually describe DID Docs. You don't set up a cryptographically secure channel over which you interact with an asteroid.

In conversations where this alternate viewpoint surfaces, I commonly hear two reactions:

Reaction A: That's not a DID use case. Use UUIDs.
Reaction B: That's a perfect DID use case. An asteroid can have an agent to facilitate digital interactions, can't it? And won't you need to talk to it (e.g., to ask its current position or to request permission to land)?

I believe neither of these reactions stands up under careful analysis, and that's why I think the topic I'm raising here is worthy of such a long email.

Here's what I think Reaction A misses: Although UUIDs are createable by anyone without central coordination, they are not resolvable. One of the wonderful properties of DIDs is that they have a defined resolution mechanism that is more decentralized than DNS, *without* requiring invisible and untrackable contextual assumptions. UUIDs lack this; you have to know to go look them up in a particular database. When people say they want a DID for asteroids, they don't just want UUID uniqueness and lack of centralized registration; they *also* want DID's resolution properties. But what they want to resolve isn't information about control, it's information about the inert object in question -- when it was first discovered, where someone can find out more, how it can be looked up on wikipedia, or dozens of other properties. (Aside: some may want another DID property as well, which is cryptographically enforced global uniqueness. UUIDs lack this property for sure. Some DID methods may lack it as well, which has been a subject of frustration on earlier threads in this group...)

This brings us to Reaction B. Proponents of this reaction would say, "You should just talk to the agent for the asteroid. No new mental model needed." But let me ask you how you think China would like it if Tibet or India registered an agent for Mount Everest. And what gives NASA or the European Space Agency the right to register (control) a DID for an asteroid that an astronomer in South Africa first observed? In other words, I think Reaction B's fatal flaw is that it thinks control is an appropriate mental model for all objects. It's not. Nobody controls a new species of mushroom that gets discovered. And nobody interacts with its agent, either. The common characteristic of asteroids, Mount Everest, biological species in a taxonomy, and other objects of this type is that they are shared concepts controlled by nobody. There must be one identifier for them, known to all--and that identifier should have no controller. Modeling them with a controller is fundamentally incorrect.

This makes me wonder if we need to be able to talk about an identifier that has the decentralized and resolvable properties of DIDs, and the pluggable methods--but that doesn't make the strong assumption that behind every DID is a control- and interaction-oriented DID Doc. Instead, it might make a lighter assumption that the DID Doc lets you discover how to learn more about an inert object.

Such an identifier could be called an "uncontrolled DID", for example. And DIDs that make the strong assumption about control could be called "DIDs" for short, or "controlled DIDs" when clarity is needed. Or we could pick other adjective pairs.

Or we could say that "DID" should only be used for the form of identifier that has strong control semantics, and that whatever the other thing is, it shouldn't be a "DID". But if we do this, we need to somehow leverage all the work we've done on DID methods and specs and documentation and implementation, without reinventing the wheel.

How would you resolve this dissonance?