Re: what do DIDs identify?

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 <X>, according to Entity <Y>"... 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) <
mwherman@parallelspace.net> 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 <trbouma@gmail.com>
> *Sent:* January 1, 2019 6:50 PM
> *To:* daniel.hardman@evernym.com
> *Cc:* Michael Herman (Parallelspace) <mwherman@parallelspace.net>; W3C
> Credentials CG (Public List) <public-credentials@w3.org>
> *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 <daniel.hardman@evernym.com>
> 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) <
> mwherman@parallelspace.net> 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 <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> 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>
> *Sent:* January 1, 2019 4:39 PM
> *To:* W3C Credentials CG (Public List) <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?
>
>
>
>
> --
>
> Find me at: http://about.me/tim.bouma
>