- From: Markus Sabadello <markus@danubetech.com>
- Date: Tue, 22 Jan 2019 15:12:36 +0100
- To: daniel.hardman@evernym.com, Joe Andrieu <joe@legreq.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <cbc3eeab-5209-3822-5fa7-f1024f73e36e@danubetech.com>
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
> <mailto: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 <mailto:daniel.hardman@evernym.com>>
> that Carlos Bruguera <cbruguera@gmail.com
> <mailto: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 <mailto: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
>> <mailto: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
>> <mailto:trbouma@gmail.com>>
>> *Sent:* January 1, 2019 6:50 PM
>> *To:* daniel.hardman@evernym.com
>> <mailto:daniel.hardman@evernym.com>
>> *Cc:* Michael Herman (Parallelspace)
>> <mwherman@parallelspace.net
>> <mailto:mwherman@parallelspace.net>>; W3C Credentials CG
>> (Public List) <public-credentials@w3.org
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto:daniel.hardman@evernym.com>>
>> *Sent:* January 1, 2019 5:36 PM
>> *To:* Michael Herman (Parallelspace)
>> <mwherman@parallelspace.net
>> <mailto:mwherman@parallelspace.net>>
>> *Cc:* W3C Credentials CG (Public List)
>> <public-credentials@w3.org
>> <mailto: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/
>>
>>
>>
>>
>>
>> 2. 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?
>>
>>
>>
>>
>> --
>>
>> Find me at: http://about.me/tim.bouma
>>
>
> --
> Joe Andrieu, PMP
> joe@legreq.com <mailto:joe@legreq.com>
> LEGENDARY REQUIREMENTS
> +1(805)705-8651
> Do what matters.
> http://legreq.com
> <http://www.legendaryrequirements.com>
>
>
Received on Tuesday, 22 January 2019 14:13:10 UTC