Re: what do DIDs identify?

Wouldn't expiry dates solve this problem? The DID expires,it is
revoked or in a state where it is not fit for authentication
("uncontrollable for update" for example).  A previous contributor
(Daniel) raised the issue of a owner (for example an org) being
unable to control their DID. I note that when an organization
dissolves (or a person dies)  the assets the entity controlled do
not usually automatically cease to exist... the
receiver/administrator of the estate usually  becomes the
'controller' of the assets.... at least until all relevant matters
are resolved.
Regards
Emmanuel   

	Hast Labs Limited, Registered in England No 3151102, VAT Reg No
710.7863.40
CONFIDENTIALITY NOTICE This e-mail message and any attachments are
only for the use of the intended recipient(s) and may contain
information that is privileged, confidential or exempt from
disclosure under applicable law. If you are not the intended
recipient, any disclosure, distribution or other use of this e-mail
message or attachments is prohibited. If you have received this
e-mail message in error, please delete and notify the sender
immediately. Thank you.

----- Original Message -----
From: "Markus Sabadello" 
To:, "Joe Andrieu" 
Cc:"Credentials Community Group" 
Sent:Tue, 22 Jan 2019 15:12:36 +0100
Subject:Re: what do DIDs identify?

	My opinion on this is that such "uncontrolled" DIDs are perfectly
legitimate and possible with the current spec, although I don't think
this requires a formal status. 

	All DIDs are "controlled" at their point of creation. This control
can be relinquished, probably through an Update operation that does
something method-specific to remove all control, e.g. zeroing out a
public key as you say. 

	This is different from revocation. A revoked DID must no longer be
used as an identifier for the subject. 

	I guess if you update a DID to be "uncontrollable", this also means
that it can never be revoked in the future, unless you distinguish
between "uncontrollable for Update" and "uncontrollable for Revoke",
this could theoretically also be supported separately by a DID
method.

	Markus
 On 1/15/19 5:57 PM, Daniel Hardman wrote:
  I accept the pushback from Carlos and Joe that the notion of a
single identifier for a shared thing is unenforceable. Point well
taken. 
 However, I am still uncomfortable with the easy assertion that DIDs
must equate with control. For example, I could answer Tom's question
("What's the point of a DID that can't authenticate") as follows: 
  When a person who controlled a DID dies (or a an org that
controlled a DID is legally dissolved), I would expect the DID that
they once controlled to continue to exist, but I would expect there
to be a way to demonstrate that the DID cannot ever authenticate
again (e.g., the public key for the DID is rotated to all zeros).
This is desirable so no future malicious actor can take over the
identity. Compare the mischief that happens with SSNs of deceased
people in the US.  
 What this suggests to me is that there needs to be a formal status
of a DID that is: "resolvable, but not controlled and therefore not
authenticatable." 
 Is this wrong? 
 --Daniel  
 On Tue, Jan 15, 2019 at 2:04 AM Joe Andrieu  wrote:
   There is a lot of misperception and misunderstanding here. Two
items stand out.

 First, DIDs are not just strings. They are URLs. They resolve to DID
Documents, either by retrieval or by construction. This is
fundamental. As some have suggested, a DID that does NOT resolve to a
DID Document is just another GUID, at best a URI but not a URL.

 Second, this notion from Daniel Hardman  that Carlos Bruguera 
quoted:
      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_.

 This is fundamentally false.

 There is no unique identifier for these things. What you call Mount
Everest some call Chomolungma and others call Sagarmatha.

 No one controls what you call it. There is no possibility that there
would be a singular DID that somehow uniquely refers to it, any more
than there would be a singular name that everyone uses in all
conversations.

 In fact, decentralized identifiers demands a framework where
literally ANYONE can refer to ANYTHING by ANY identifier it wants.
Any perspective that suggests "there must be one identifier" for
anything is a form of centralization and antithetical to the notion
of directed identity aka pairwise identifiers.

 THAT said, it may be more useful to consider "actors" in this
context purely as entities capable of generating the proofs in a DID
Document. For example, a secure module that is part of an engine
control system could use an embedded private key to generate proofs
that meet the requirements for authentication without ever revealing
its internal key.

 In this framing, it is perfectly reasonable to have DIDs that refer
to passive actors, capable only of interrogatory responses to verify
said actors' provenance aka identity. Think of it as a
cryptographically secure Vehicle Identification Number (VIN). 
 Of course, it's a bit more interesting to think of that engine
autonomously interacting with the world, making it more of an "actor"
in the UML sense, an "agent" to others, but we don't need to dissect
the finer nuances of these terms. What matters is that the DID
controller can perform the math to prove control. And that any entity
seeking to authenticate as the referent of a DID is capable of
performing the math associated with authentication.

 In short, the point of the bitcoin revolution that spawned DIDs is
that the proof is in the math. Period. Assumptions about autonomy or
humanity or keys being in the hands of a particular individual are
groundless leaps of faith.

 -j 

 On Mon, Jan 14, 2019, at 11:11 PM, Tom Jones wrote:
   what's the point of a did that cannot authenticate?
  It may as well be a guid
    Peace ..tom

  On Mon, Jan 14, 2019 at 10:09 PM Carlos Bruguera  wrote:
    Interesting topic, and thanks Daniel for putting together this
perception divergence. I do think it's a relevant discussion in this
early stages of conception and design of DIDs.

 I'd like to share a few personal views on the matter.

 The motivator for DIDs is indeed SSID, in which _Actors _will be at
the core of the ecosystem. Yet inanimated things (even abstract
"things") are also part of the world we live in, and they will
inevitably have a role in digital interactions among self-sovereign
entities.

 I agree that a (sufficiently autonomous) "thing" can perfectly be an
actor, and I don't think it's wise enough to assume that these things
will ALWAYS be associated to a "non-thing" that is able to "control"
them (or even be legally accountable, but that's whole different
subject). I see no issues with a self-driving car or a DAO having a
DID or a set of DIDs with which they can _interact_ with other
entities of any kind, while being themselves "self-sovereign" in a
manner of speaking. Any legal/philosophical doubts regarding this are
probably outside the scope of at least the (technical) _possibilities_
for DIDs. I think we should leave this technical possibilities open,
while addressing their social implications according to each specific
use case and in their corresponding layers.

 Now, the problem sure comes with entities that can take NO POSSIBLE
ACTION within a system, in which it seems there's little point in
having DIDs, yet on the other hand allowing these "things" to enjoy
the resolvability of DIDs (among other properties) certainly brings
more "expressive power" to DIDs, which will translate to a wider
potential of applications that can be built on SSID. However, I think
there's a problem with the bold part of the following statement:

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

  Since these things certainly cannot be modeled in terms of control,
then it doesn't seem possible that there is a "one (and only)
identifier" for them, since who has then the right or responsibility
to define the attributes and identifiers for such things? It seems to
me that this is more a case for _verifiable claims_, since there's
nothing stopping anyone to freely assert public attributes to Mount
Everest or an asteroid or a biological species and publish
identifiers for them according to some method. So then, upon
resolving these DIDs there comes a matter of _trust_ on the entity
that created them, thus you might choose to resolve and use the
"Fungi X Taxonomy according to John Doe (or Institution Y)" or a
different one whose source you may trust more or less. Again, it
seems we're talking either about _claims_ or a very similar concept.
I just don't see how it's possible to grant _unique_ and final
identifiers to "inanimate" things in a self-sovereign manner (i.e.
without establishing central "authorities" in charge of the
identification process).

 Perhaps we should then expand the scope of public claims to cover
the act of _identifying_ non-actor things using DIDs, or allow public
claims themselves to have DIDs that can be resolved and (in this case)
interpreted as "This DID RESPRESENTS Object , according to Entity "...
In the end, philosophically speaking, the only thing we can
conventionally share about the world we interact with (and which we
do not control) is our subjective representation of it.

 Looking forward to read other people's opinions on the matter.

 Regards,
 Carlos

  On Wed, Jan 2, 2019 at 10:05 AM Michael Herman (Parallelspace) 
wrote:

	Tim, again, this is an example where I believe the term DID isn’t
being used properly.  

	 

	A DID is only a character-string identifier …it’s not anything
more than that.  Agreed?

	 
  FROM: Tim Bouma  
  SENT: January 1, 2019 6:50 PM
  TO: daniel.hardman@evernym.com [7]
  CC: Michael Herman (Parallelspace) ; W3C Credentials CG (Public
List) 
  SUBJECT: Re: what do DIDs identify?

	 

	Hi everyone,

	 

	My simplified view is that DIDs are under the control of Agents
(software or hardware), which in turn can be attributed to, or held
accountable by Actors (Individuals, Organizations).

	 

	Things, in my view, are just a type of Agent.

	 

	If an Agent (autonomous, friendly, or otherwise) cannot be
attributed or accountable to an Actor (i.e., Principal), you have a
legal, not a technical problem on your hands. 

	 

	What is missing in the entity model, is the notion of Relationship
I believe this model can be simplified to Individuals, Organizations,
and Relationships, the details of which can be scoped out of the
technical architecture.

	 

	In the end, Agents control DIDs, for the purpose of interacting with
other Agents. Agents need to be attributable to Actors if they are to
be trusted in any manner.

	 

	Whether an Agent is autonomous, liable, or not (such as a car) is
really a question for the legal (or trust) frameworks, not
necessarily addressed by the technical architecture.

	 

	Best regards,

	 

	Tim

	 

	 

	 

	 

	 

	 

	 

	On Tue, 1 Jan 2019 at 20:27, Daniel Hardman  wrote:

	I can agree partly. The chassis and engine of a car is not really an
actor, and the software running a self-driving car IS. But I don't
think that division is particularly crisp. The harder you look at it,
the muddier it becomes. Where does software end and hardware begin, if
programmable chips are involved? Does the software that gathers and
processes signals from sensors deserve to be thought of as part of
the actor--or only the part that makes decisions?

	 

	But I totally diverge on your last sentence. Yes, the owners of a
car are the ones that get sued. But that doesn't make them actors in
some special sense different from the way software is an actor.
Actors are just entities that make decisions. Being susceptible to
lawsuit doesn't make an entity an actor; it gives them legal
standing. Those are two quite different concepts.

	 

	 

	On Tue, Jan 1, 2019 at 5:59 PM Michael Herman (Parallelspace) 
wrote:

	RE: A self-driving car is an actor; it's just one that is owned and
operated by another actor.

	 

	This is another instance of the architectural terminology problem. 
The car is not an Actor.   

	 

	The car is a component of the Technology/Infrastructure Layer. 
…that is, the car is the nuts-and-bolts vehicle with its propulsion
system (engines, motors, fuel system etc.), suspension system (tires,
maglev, etc.), vision/auditory/proximity/temperature/road conditions,
etc, sensors, etc, etc, etc.  The car is not an Actor …at least,
not technically an Actor …until it hits someone, of course.

	 

	The Actor in this scenario is the software agent(s) in the car as
well as in the vendor(s) cloud(s) that are controlling this piece of
nuts-and-bolts infrastructure.  IMHO ;-)

	 

	When the car does hit someone, they don’t sue the car …they sure
the Actors …the owners of the software agent(s).

	 

	Michael

	 

	 
  FROM: Daniel Hardman  
  SENT: January 1, 2019 5:36 PM
  TO: Michael Herman (Parallelspace) 
  CC: W3C Credentials CG (Public List) 
  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
[15]. 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) 
wrote:

	* 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/
[17]

	 

	 

	* 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/
[18]

	 

	Best regards,

	Michael Herman (Toronto/Calgary/Seattle)

	 
  FROM: Daniel Hardman  
  SENT: January 1, 2019 4:39 PM
  TO: W3C Credentials CG (Public List) 
  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?

	 

	-- 

	Find me at: http://about.me/tim.bouma [21]

  --
 Joe Andrieu, PMP                                  
                                         
 joe@legreq.com [22]
   LEGENDARY REQUIREMENTS                            
                           +1(805)705-8651
  Do what matters.                                  
                                       
 http://legreq.com [23]

 

Links:
------
[1] mailto:joe@legreq.com
[2] mailto:daniel.hardman@evernym.com
[3] mailto:cbruguera@gmail.com
[4] mailto:cbruguera@gmail.com
[5] mailto:mwherman@parallelspace.net
[6] mailto:trbouma@gmail.com
[7] mailto:daniel.hardman@evernym.com
[8] mailto:mwherman@parallelspace.net
[9] mailto:public-credentials@w3.org
[10] mailto:daniel.hardman@evernym.com
[11] mailto:mwherman@parallelspace.net
[12] mailto:daniel.hardman@evernym.com
[13] mailto:mwherman@parallelspace.net
[14] mailto:public-credentials@w3.org
[15]
https://github.com/hyperledger/indy-hipe/tree/master/text/0014-ssi-notation#entities
[16] mailto:mwherman@parallelspace.net
[17]
https://hyperonomy.com/2018/12/21/decentralized-identifiers-dids-architecture-reference-model-arm/
[18]
https://hyperonomy.com/2018/12/21/decentralized-identifiers-dids-architecture-reference-model-arm/
[19] mailto:daniel.hardman@evernym.com
[20] mailto:public-credentials@w3.org
[21] http://about.me/tim.bouma
[22] mailto:joe@legreq.com
[23] http://www.legendaryrequirements.com