Re: what do DIDs identify?

I'm confused about the relationship between DIDs and VCs in the context of
revocation. See https://github.com/w3c-ccg/did-resolution/issues/5

Adrian

On Tue, Jan 22, 2019 at 12:36 PM Emmanuel Forche <forchee@hastlabs.com>
wrote:

> 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" <markus@danubetech.com>
>
> To:
> <daniel.hardman@evernym.com>, "Joe Andrieu" <joe@legreq.com>
> Cc:
> "Credentials Community Group" <public-credentials@w3.org>
> 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 <joe@legreq.com> 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 <daniel.hardman@evernym.com>
>> that Carlos Bruguera <cbruguera@gmail.com> 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 <cbruguera@gmail.com>
>> 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 <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 (ie., 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
>>
>>
>> --
>> Joe Andrieu, PMP
>>                      joe@legreq.com
>> LEGENDARY REQUIREMENTS
>>      +1(805)705-8651
>> Do what matters.
>>                    http://legreq.com
>> <http://www.legendaryrequirements.com>
>>
>>
>>
>

-- 

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/