- From: Markus Sabadello <markus@danubetech.com>
- Date: Tue, 22 Jan 2019 15:02:01 +0100
- To: public-credentials@w3.org
- Message-ID: <0a24d4ad-9684-52c0-7d6d-36abaf1ed977@danubetech.com>
FYI there's a Github issue on the topic of how revoked DID should work
during resolution:
https://github.com/w3c-ccg/did-resolution/issues/5
And an older thread:
https://lists.w3.org/Archives/Public/public-credentials/2018Jun/0078.html
Markus
On 1/15/19 7:19 PM, Joe Andrieu wrote:
>
> On Tue, Jan 15, 2019, at 8:57 AM, 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:
>
> It is control of DIDs that define them. In centralized identity
> architectures, there is an authority who can control everything:
> delete accounts, reset passwords, in some cases even impersonate
> users, and most usually they delegate control to users.
>
> The point of DIDs is that they use a decentralized layer (blockchain,
> IPFS, etc.) to enable control for updates and authentication as the
> referent of the DID, WITHOUT a central authority.
>
> There will absolutely be DIDs that no one actually controls--because
> the private keys are lost. That's just a consequence of a lack of
> administrative authority who can recover control by fiat.
>
> Unfortunately, there is no general way to know if the keys are lost.
>
> However, it is possible to revoke DIDs, which could be on
> interpretation of what you're actually asking for. However, not all
> methods support resolving a revoked DID to a DID Document that somehow
> indicates it is revoked.
>
> There has been some discussion about whether or not methods should
> return a different result for a revoked DID versus a non-DID (there's
> no record of it and therefore no DID Document to resolve to), but
> there is no consensus other than that this seems to be best left up to
> individual methods.
>
> It *might* be interesting for DID methods to require an entry in the
> authentication property in order to authenticate, but some methods
> simply use the control proof for authentication.
>
> Note also that it is explicitly permitted to authenticate as a DID
> without being the controller of the DID. As such, you could in fact
> have an uncontrolled DID (the initial key required for
> proof-of-control is lost) but for which a valid authentication entry
> allows a different key to authenticate as the referent of the DID.
>
> Finally, the current spec has a lot of out-dated text about ownership.
> There has been a developing consensus that owner and ownership are an
> unfortunately misleading terms and the intent is to shift to
> "controller" as a more appropriate term.
>
> See
> https://github.com/w3c-ccg/did-spec/issues/153
> https://github.com/w3c-ccg/did-spec/issues/108
> https://github.com/w3c-ccg/did-spec/issues/101
>
> As well as your
> own https://github.com/w3c-ccg/did-spec/issues/148 which I just
> commented on.
>
> -j
>
>>
>> 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>
>>
>>
>
> --
> 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:02:36 UTC