Closed jandrieu closed 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.
Spoke with @jandrieu and @talltree, they're good to close this issue. Closing.
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
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
@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?
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".
You could say that. ;)
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.
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.
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.
- The entity (A) being observed for the sake of recognition
- The profile (B) in the database that Entity A is recognized as
- 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 .
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:
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.