Change "identity" language to "identifier".

[msporny]

This is the first set of changes needed to move us from talking about "identity" to talking about "identifiers".

---

Preview | Diff

[jandrieu]

Abstract suggestion:

Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, "self-sovereign" digital identity. DIDs are fully under the control of the subject entity, independent from any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a subject entity to means for trustable interactions with that entity. DIDs resolve to DID Documents — simple documents that describe how to use that specific DID. Each DID Document may contain three things: authentications, authorizations, and endpoints. The first is the set of mechanisms to authenticate as the entity associated with a particular DID (e.g. public keys, pseudonymous biometric templates, etc.). The second is the set of mechanisms for authorizing modifications to the DID Document. The third is a set of service endpoints for trusted interactions with the entity. This document specifies a common data model, format, and operations that all DIDs support.

[jandrieu]

For the second paragraph in 1.1 Overview:

The emergence of distributed ledger technology (DLT), sometimes referred to as blockchain technology, provides the opportunity for fully decentralized identity management. In a decentralized identity system, entities are free to use any shared root of trust. Globally distributed ledgers (or a decentralized P2P network that provides similar capabilities) provide a means for managing a root of trust with neither centralized authority nor a single point of failure. In combination, DLTs and decentralized identity systems enable any entity to create and manage their own identifiers on any number of distributed, independent roots of trust.

[jandrieu]

I believe the term "owner" should be changed, either to "controller" to "subject". When proposing amendments to the abstract and introduction, it seemed clearest to refer to entity referred to by a DID as the subject entity: that a DID links the identifier of a subject to the means for secure interactions with (or about) that subject.

This note is NOT related to the PR but rather a note to frame future conversation. I realize we have had multiple conversations about owner/controller/subject, etc. We're not done yet.

[msporny]

subject entity

I :+1:'d your updates in general. I do wince a bit at the term "subject entity", it feels like a very specific term of art where people will get confused about it. I'll apply your changes, anyway, but reserve complete agreement until we have that discussion. In any case, it's not something that should slow down this PR. We can iterate. PR updates forthcoming.

[jandrieu]

Yeah, subject entity may not be quite right. I was trying to pull in the work from functional identity, where the "subject" is what the identifier refers to. That led me to realize that while a self-sovereign use of DID would mean that the subject controls the DID, technically, there is no reason that the subject must control the DID. That, in turn, made me think we need to tease out a distinction between the entities authorized to control a DID (controllers) from the entity referred to by the DID (the subject). Because of delegation and things like social recovery, these two are not only distinct, they may have different plurality, i.e., there might be many controllers associated with a single subject. For all of that "owner" seems like a particularly poor choice as legal ownership could be construed any number of ways and is probably a distraction from control and subject, which are more functional than legal.

Personally, I'm ok with calling the subject referred to by a DID a simply the Subject. Maybe "entity" is what is extraneous here.

[ChristopherA]

For cryptocurrencies, this might be called "custody". For instance, in a 2 of 2 multisig with a timelock returning control to the 1st signature at expiration, the custody of currency is considered to be held by the 1st signature, not the 2nd. Without the timeline it would be considered dual custody. I anticipate using similar constructions for BTCR.

Don't know if "custodian" is the right answer though — could be confused with "guardian". Difficult naming problems these!

[msporny]

For all of that "owner" seems like a particularly poor choice

I think we have general agreement that owner is probably not the right term. I'd be fine w/ hand-waving in the abstract and intro on "subject", but haven't had a chance to try out the language in a PR.

Don't know if "custodian" is the right answer though

It feels better than owner... but I agree that it might be confused w/ guardian. Remember that we're moving to the "delegation" terminology. So perhaps putting it in sentence form might help:

• The DID Document describes authentication, authorization, and services related to a X.
• The X may delegate management of their DID Document to a Y.

To me, it seems like X === "subject" and Y === "guardian" makes sense. The same where Y === "custodian". I'll try some of this language out in the PR when I get a spare moment.

[Drabiv]

My 2 cents, if I may. I would vote for simple "entity". Why "entity" cannot be used? It would fit into these examples:

• The DID Document describes authentication, authorization, and services related to a X.
• The X may delegate management of their DID Document to a Y.

[msporny]

@Drabiv wrote:

I would vote for simple "entity". Why "entity" cannot be used?

Entity is our most generic form of "thing" we talk about, so it may be too generalized. That said, I like "entity" too... @jandrieu, @ChristopherA, do you guys think we can get away with "entity"?

[talltree]

Manu is right that the problem with "entity" is that it is the most general term we have. And "entity" only works if you use it in context, i.e., "the entity identified by a DID".

So I like the idea of standardizing on "subject" as the single term for describing "the entity identified by a DID".

What's the argument against using "subject" for that?

On Tue, Dec 12, 2017 at 9:10 AM, Manu Sporny notifications@github.com wrote:

@Drabiv https://github.com/drabiv wrote:

I would vote for simple "entity". Why "entity" cannot be used?

Entity is our most generic form of "thing" we talk about, so it may be too generalized. That said, I like "entity" too... @jandrieu https://github.com/jandrieu, @ChristopherA https://github.com/christophera, do you guys think we can get away with "entity"?

— You are receiving this because your review was requested. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/did-spec/pull/36#issuecomment-351061807, or mute the thread https://github.com/notifications/unsubscribe-auth/ADLkTTlqCS49q9i8htfv2i_QDYaIoWiFks5s_ok9gaJpZM4QzbrN .

[talltree]

This thread is covering a lot of territory, so I don't know whether to bring this up here, but I am concerned about this phase from Joe's suggestion for the abstract: "Each DID Document may contain three things: authentications, authorizations, and endpoints." That's not how I would describe a DID document. Where should we discuss this?

[msporny]

That's not how I would describe a DID document. Where should we discuss this?

Since the PR raised the question, we should start the discussion here and move it to the CCG if we can't come to consensus on that text. Suggest some alternative text and we can go from there.

[msporny]

What's the argument against using "subject" for that?

It's too general is the only argument I can think of... :) ... and I don't think I buy that argument. Feels like it's the right level of abstraction.

[dlongley]

I think a DID document is about establishing an independent entity and being able to authenticate that certain activities/actions were performed by that entity -- and to interact with that entity via services. This necessarily includes specifying how that DID document can be changed.

I think "Each DID Document may contain three things: authentications, authorizations, and endpoints." covers those things -- but I'm open to other language.

[jandrieu]

To iterate on @dlongley's language: a DID document establishes how to interact with an independent entity. Based on our conversation today, I'd like to suggest "authentication, modification, and services".

An updated abstract:

Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, "self-sovereign" digital identity. DIDs are the first globally verifiable identifiers with the potential to be fully under the control of the subject, independent from any centralized registry, identity provider, or certificate authority. DIDs resolve to DID Documents — simple documents that describe how to use that specific DID. DID Documents contain three sections: authentication, modification, and services. The first is the set of mechanisms to authenticate interactions as originating from the subject (e.g. public keys, pseudonymous biometric templates, etc.). The second is the set of mechanisms for modifying the DID Document. The third is a set of service endpoints for trusted interactions with the subject.

DIDs are open domain URLs that relate a subject to means for secure interactions with that entity: unlike traditional URLs, DIDs depend on neither the Domain Name System nor IP addresses (although services using DIDs may), instead using distributed approaches to manage authoritative DID resolution.

This document specifies a common data model, format, and operations that all DIDs support.

[jandrieu]

Note: I was compelled to try out some language explaining that DIDs are URLs, but not dependent on DNS or even IP addresses. I referred to this as "open domain" URLs. I had also considered "domain-free" URLs, but that didn't quite seem right to me.

Is there a way to concisely name a URL that doesn't use the DNS/IP domain architecture?

[dlongley]

@jandrieu,

Is there a way to concisely name a URL that doesn't use the DNS/IP domain architecture?

Just "URL". file:///tmp/foo.txt is a URL.

That doesn't mean that it isn't worth explicitly noting that there's no dependency on DNS ... but I don't know that we need to qualify "URL" itself to express that.

[jandrieu]

Understood. Lots of URLs don't have the "domain part" that anchors http URLs. I'm just exploring language for highlighting that. It seems worth pointing out in the abstract.

[Drabiv]

What's the argument against using "subject" for that?

"Subject" is a loaded term, contrary to "entity" that has only one meaning. Try to search in google "define:subject" vs. "define:entity".

Using "subject" vs. "entity" effects the way we think about, or explain DIDs. When "entity" is used the explanation goes something like this – "There is a world full of entities (people, organizations, things, virtual entities). They can be identified with identifiers. DIDs are identifiers that are stored in DLTs." When "subject" is used the explanation will go like this – "There are identifiers. They identify subjects. ..." You cannot naturally say "There are subjects. They are identified by identifiers." So when using "subject" term we put identifiers into the first place.

When reading about "identity" topic - it is mostly explained in terms of entity and information related to entity. I have not seen much identity writings that use "subject" term.

If "subject" is considered why not use "object" then, – "DIDs are identifiers that identify some objects". Then when thinking about "subject" vs. "object", and why "subject" was chosen it becomes apparent that subject implies active role of an entity in creation and controlling identifier. But then I think (correct me if I am wrong) there may be use cases in IoT when DIDs are established for things and those things do not play active role in managing their DIDs and DDOs.

In conclusion, because "subject" is a loaded term it imply many things, causing cognitive dissonance and understanding of DIDs "subject" implies "a topic of identifier", "a thing that identifier identifies (talks about)" "subject" implies that there is an "active actor, some thing that has agency who created and controls identifier" "subject" also may implies that identifier is more important than entity, – "first there is an identifier, it identifies subject", there cannot be "first there is subject, it is identified by identifier".

In my opinion it would be simpler and more natural to use "entity" term. Entity does not have any connotation in regards to agency and it has one simple meaning – a thing, a person, a being, something that exist within limited boundaries.

Pardon me if this rant is too philosophical for this particular issue by I think it is important.

[jandrieu]

@Drabiv the term "subject" has considerable background in both RDF and identity, and is a well-understood part of the Verifiable Claims conversation. If you haven't read it, I recommend my own primer on Functional Identity https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/functional-identity-primer.md

The main distinction of "subject" from "entity" is that it describes the role of the thing in the system, which is that it is the referent of the DID, aka the thing it is referring to.

There are multiple entities involved in most interesting interactions. For Verifiable Claims, we have issuers, holders, verifiers, and subjects. Each of those have different roles and the distinction between roles is important when discussing how it all works. Each of them can also all be entities. So, using just "entity" becomes so generic as to lose the functional point of the conversation.

[Drabiv]

@jandrieu thanks for the primer. It looks great from the first glance. I will definitely read it. I get your point why "subject" term should be used, but I still like "entity" more. I see that "subject" is a better descriptor of the role of the thing within a system; and "subject" better describes the place of the element within DID Document from identifier perspective. But because it is so loaded term, and because "entity" is so simple, I still prefer "entity". Issuer, holder, verifier names are self-descriptive and they probably will not be confused with entity. So if there would be a vote I would vote for "entity" still, but probably, it is just me... Maybe I'll change my mind after reading more on digital identity including your Functional Identity primer.

[talltree]

I was going to make the same point as Joe but as usual he said it more eloquently.

Since I am writing constantly about DIDs, I'll also explain this semantic problem I've run into with "entity". "Entity" is so general that if you try to refer to "the entity identified by a DID" at the "DID entity", it introduces the confusion of whether the "DID entity" is the DID document itself, rather than the subject of the DID (and a DID document is never the subject of a DID).

This confusion is avoided when you say "DID subject".

On Thu, Dec 14, 2017 at 8:59 AM, Bohdan Andriyiv notifications@github.com wrote:

@jandrieu https://github.com/jandrieu thanks for the primer. It looks great from the first glance. I will definitely read it. I get your point why "subject" term should be used, but I still like "entity" more. I see that "subject" is a better descriptor of the role of the thing within a system; and "subject" better describes the place of the element within DID Document from identifier perspective. But because it is so loaded term, and because "entity" is so simple, I still prefer "entity". Issuer, holder, verifier names are self-descriptive and they probably will not be confused with entity. So if there would be a vote I would vote for "entity" still, but probably, it is just me... Maybe I'll change my mind after reading more on digital identity including your Functional Identity primer.

— You are receiving this because your review was requested. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/did-spec/pull/36#issuecomment-351717968, or mute the thread https://github.com/notifications/unsubscribe-auth/ADLkTXkt9Bym86P8VEJkXqPE3G0hNE7jks5tASmwgaJpZM4QzbrN .

[msporny]

I had to manually rebase this on master after applying further changes from @talltree and @jandrieu that I think resolve everything. The language is still a bit unwieldy, but reflects all of the conversations in this thread and that we had during the DID Hardening discussions.