- From: Tom Jones <thomasclinganjones@gmail.com>
- Date: Mon, 14 Jan 2019 23:11:20 -0800
- To: Carlos Bruguera <cbruguera@gmail.com>
- Cc: "Michael Herman (Parallelspace)" <mwherman@parallelspace.net>, Tim Bouma <trbouma@gmail.com>, "daniel.hardman@evernym.com" <daniel.hardman@evernym.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CAK2Cwb4N_WjEd0n9kxYju--nL2KNs_LYydXSpEm496GY-5zVvw@mail.gmail.com>
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 (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 >> >
Received on Tuesday, 15 January 2019 07:12:01 UTC