search

w3c-ccg / did-spec

Please see README.md for latest version being developed by W3C DID WG.
https://w3c.github.io/did-core/
Other
125 stars 45 forks source link

Clarify DIDs help manage identifiers, not identities #23

Closed jandrieu closed 6 years ago

jandrieu commented 6 years ago

As discussed in the conversation about https://github.com/w3c-ccg/did-spec/pull/22, the current language around DIDs slips into expansive language about "identities" where the more rigorous language really should be about "identifiers"

I'll start with the top level:

The emergence of distributed ledger technology (DLT), sometimes referred to as blockchain technology, provides the opportunity to implement fully decentralized identity management. In this ecosystem, all participants with identities (called identity owners) share a common root of trust in the form of a globally distributed ledger (or a decentralized P2P network that provides similar capabilities).

This sentence captures a broad disconnect I believe we can easily fix.

DIDs do not provide decentralized identity management. They provide decentralized identifier management.

There's a huge difference.

We're generally on the same page about the opportunity for decentralized identity, but DIDs are just the first step and I think we would do better to be strict in our claims.

DIDs do not address attribute management (classic ISO definition of identity), nor do they address attribute derivation, analysis, use, and protection (from the functional definition of identity).

I started adding a bunch of +1 to @dlongley's comments for replacing "identity owner" with "entity" and realized a simpler, but more sweeping change to focus on DIDs as providing a means to prove control of "identifiers" rather than "identities" would greatly improve the entire spec.

Note that even with the stricter language of identifiers and the smaller scope, DIDs still solve a unique problem in a way that is game changing. I'd like to see we capture that in the most elegant and modest manner possible without conflating DIDs with much larger issues they don't actually address.

msporny commented 6 years ago

I believe this was addressed at some point along the way (you can see that the spec has been updated to use the word "identifier" in a large number of places). We will need @jandrieu and @talltree to review the spec to make sure the appropriate changes were made.

msporny commented 6 years ago

Spoke with @jandrieu and @talltree, they're good to close this issue. Closing.

Cahl-Dee commented 5 years ago

As noted above, DID =/= Identity, but one thing that's not abundantly clear to me is the relationship of a DID to an Identity. While it's clear that an entity can have many DIDs, it's even recommended to have a new one for every interaction where you do not want to be correlated, does that mean the entity has multiple identities each with one DID, or a single identity with many DIDs?

In short, an Identity entails the entire history for a: a) DID b) entity, across DIDs

talltree commented 5 years ago

On Thu, Jun 13, 2019 at 2:11 PM Cahl-Dee notifications@github.com wrote:

As noted above, DID =/= Identity, but one thing that's not abundantly clear to me is the relationship of a DID to an Identity. While it's clear that an entity can have many DIDs, it's even recommended to have a new one for every interaction where you do not want to be correlated, does that mean the entity has multiple identities each with one DID, or a single identity with many DIDs?

In short, an Identity entails the entire history for a: a) DID b) entity, across DIDs

Whew, this gets perilously close to the rathole of "what is identity"—a conversation I have sworn (after 20 years in this industry) never to have again.

So, my way of doing that is to simply clarify the subject line of this thread, which is that a DID is an IDENTIFIER, pure and simple, and that identifiers are frequently (but not always) one component of what is widely considered an "identity".

If you want a much more nuanced answer—from the standpoint of a three-year old project devoted exclusively to establishing a global public utility for SSI based on these open standards—let me refer you to Appendix A of the Sovrin Glossary https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit?pli=1#heading=h.8bjtfwpx6fwe that carefully distinguishes between entities, identities, identity data, and DIDs, complete with a concept map developed by the Sovrin Governance Framework Working Group (hat tip to Andrew Hughes. who led the work).

=Drummond

Cahl-Dee commented 5 years ago

@talltree thanks for your quick reply!

To be sure I'm understanding, what you're saying is that identities typically (but not always) have a one to one mapping to a DID. Is that correct?

talltree commented 5 years ago

On Thu, Jun 13, 2019 at 6:22 PM Cahl-Dee notifications@github.com wrote:

@talltree https://github.com/talltree thanks for your quick reply!

To be sure I'm understanding, what you're saying is that identities typically (but not always) have a one to one mapping to a DID. Is that correct?

Yes, that's what I'm saying. The definition of "an identity has a one-to-one mapping to a DID" is specifically how the Sovrin community chose to define it in the Sovrin Glossary. As shown in the diagram below from Appendix A of the Sovrin Glossary, we found that it is the most precise way to define contextual self-sovereign identities.

However, not everyone may agree that is their definition of "identity".

jandrieu commented 5 years ago

You could say that. ;)

jandrieu commented 5 years ago

To wit: there are identities without DIDs (did your great grandmother have a DID?) and DIDs without identities (we can algorithmically construct as many as we want without any actual referent intended or recognized). The Sovrin definition should be considered in context of what Sovrin is doing as a whole, rather than applied outside that context.

DIDs are identifiers, which refer abstractly and variously to entities. Any entity may be the subject of zero, one, or many DIDs and they may or may not control them. In turn DIDs refer to a single subject although a DID that refers to multiple entities is viewed as referring to a single group entity that happens to contain the referred-to entities.

An observer might use a DID, and DID Document, to gather evidence to construct an identity for the DID Subject. That is, DIDs can help a DID Subject establish an identity with an observer aka relying party aka verifier. Either through some form of DID Auth or the accumulation of DID-referencing credentials, that observer might recognize an entity as the DID Subject. That recognized entity might be a candidate subject--an unknown entity that is present at a service claiming a certain identity. Or, it could be a subject profile--about an entity known to the system from some prior data source or interaction.

The language here gets muddy between three different objects of interest.

  1. The entity (A) being observed for the sake of recognition
  2. The profile (B) in the database that Entity A is recognized as
  3. The entity (C) whom the observer believes who the profile (B) is about.

An identity doesn't exist until A is matched to B, although the industry often discusses the mechanisms of that recognition as they were "identities", e.g., referring to both profiles and credentials as "identities". ISO even defines "identity" as attributes related to an entity (#2), despite the obvious awareness that identities pre-date digital profiles.

Thing is... when it all works, when a reliable identity is established A, B, and C are in harmony. The information in B will in fact be about both C and A, which allows the observer to interact with A as if they are C, with faith that the information they are basing that interaction on, B, is accurate.

The language problems arise when these things aren't in harmony. When A is not C. Or when B isn't actually about A, or even about C. The longstanding industry vernacular that discusses A, B, and C as if they are all "identities" is part of why @talltree and others are tired of (re)defining identity every time someone tries to untie the gordian knot of A?=B?=C.

talltree commented 5 years ago

Brilliantly said, Joe. Especially the "untying the gordian knot" part.

On Fri, Jun 14, 2019 at 9:58 AM Joe Andrieu notifications@github.com wrote:

To wit: there are identities without DIDs (did your great grandmother have a DID?) and DIDs without identities (we can algorithmically construct as many as we want without any actual referent intended or recognized). The Sovrin definition should be considered in context of what Sovrin is doing as a whole, rather than applied outside that context.

DIDs are identifiers, which refer abstractly and variously to entities. Any entity may be the subject of zero, one, or many DIDs and they may or may not control them. In turn DIDs refer to a single subject although a DID that refers to multiple entities is viewed as referring to a single group entity that happens to contain the referred-to entities.

An observer might use a DID, and DID Document, to gather evidence to construct an identity for the DID Subject. That is, DIDs can help a DID Subject establish an identity with an observer aka relying party aka verifier. Either through some form of DID Auth or the accumulation of DID-referencing credentials, that observer might recognize an entity as the DID Subject. That recognized entity might be a candidate subject--an unknown entity that is present at a service claiming a certain identity. Or, it could be a subject profile--about an entity known to the system from some prior data source or interaction.

The language here gets muddy between three different objects of interest.

  1. The entity (A) being observed for the sake of recognition
  2. The profile (B) in the database that Entity A is recognized as
  3. The entity (C) whom the observer believes who the profile (B) is about.

An identity doesn't exist until A is matched to B, although the industry often discusses the mechanisms of that recognition as they were "identities", e.g., referring to both profiles and credentials as "identities". ISO even defines "identity" as attributes related to an entity (#2 https://github.com/w3c-ccg/did-spec/pull/2), despite the obvious awareness that identities pre-date digital profiles.

Thing is... when it all works, when a reliable identity is established A, B, and C are in harmony. The information in B will in fact be about both C and A, which allows the observer to interact with A as if they are C, with faith that the information they are basing that interaction on, B, is accurate.

The language problems arise when these things aren't in harmony. When A is not C. Or when B isn't actually about A, or even about C. The longstanding industry vernacular that discusses A, B, and C as if they are all "identities" is part of why @talltree https://github.com/talltree and others are tired of (re)defining identity every time someone tries to untie the gordian knot of A?=B?=C.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/did-spec/issues/23?email_source=notifications&email_token=AAZOITNFROP6WPCPSGOSJY3P2PE3JA5CNFSM4D3N5DO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXXMIYY#issuecomment-502187107, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZOITLS7NTXDY56Z6YFGJTP2PE3JANCNFSM4D3N5DOQ .