Difference between revisions of "Distributed ID"
From MgmtWiki
(→References) |
(→References) |
||
| (44 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
==Context== | ==Context== | ||
Every one knows the problem with identities on the internet. They are not under the control of users, who are extremely interested in their own [[Identity]] and want their own [[Privacy]]. | Every one knows the problem with identities on the internet. They are not under the control of users, who are extremely interested in their own [[Identity]] and want their own [[Privacy]]. | ||
| − | * [[ | + | * [[Decentralized ID]] (DID) is a somewhat different concept in that it envisions an [[Identifier]] which is crated by the user, and could serve as a basis for a [[Distributed ID]], but does not address the relationship to other [[Identifier]]s. |
* The current paradigm in open identity is for each conforming [[Relying Party]] to provide a list of [[Identifier or Attribute Provider]]s that the [[User]] could chose from to allow access. | * The current paradigm in open identity is for each conforming [[Relying Party]] to provide a list of [[Identifier or Attribute Provider]]s that the [[User]] could chose from to allow access. | ||
** In this model it was up to the [[Relying Party]] to establish a link and share a secret with the [[Identifier or Attribute Provider]] in advance of any transactions. | ** In this model it was up to the [[Relying Party]] to establish a link and share a secret with the [[Identifier or Attribute Provider]] in advance of any transactions. | ||
** It also required the user to pre-register with one or more of those providers, typically one of the big social sites, like: Google, Microsoft or Facebook. | ** It also required the user to pre-register with one or more of those providers, typically one of the big social sites, like: Google, Microsoft or Facebook. | ||
| − | * The current most common protocol for some sort of a [[Distributed Identity]] was [[OpenID Connect]] which included [[Self-issued | + | * The current most common protocol for some sort of a [[Distributed Identity]] was [[OpenID Connect]] which included [[Self-issued Identifier]], but that feature of [[OpenID Connect]] had not been deployed in 2018. |
| − | + | The following evaluation is based on the goals as listed in the spec. | |
| + | {| class="wikitable" | ||
| + | |- | ||
| + | | # || Goal|| Description in draft of 2020-01-22|| Status | ||
| + | |- | ||
| + | | 1 || [[Decentralization]] || Eliminate the requirement for centralized authorities or single point failure in identifier management, including the registration of globally unique identifiers, public verification keys, service endpoints, and other metadata. || Spec does not achieve this | ||
| + | |- | ||
| + | | 2 || Control || Give entities, both human and non-human, the power to directly control their digital identifiers without the need to rely on external authorities. || Some authority needs to validate user agent code. There appears to be not reason to allow untrusted connections on the web, that is HTTPS which depends on identifier of the web site. | ||
| + | |- | ||
| + | | 3 || Privacy || Enable entities to control the privacy of their information, including minimal, selective, and progressive disclosure of attributes or other data. ||Originally [https://hackylawyer.com/f/forget-erasure-why-blockchain-is-really-incompatible-with-gdpr not even compliant with GDPR] See update in problems below. | ||
| + | |- | ||
| + | | 4 || Security || Enable sufficient security for relying parties to depend on DID documents for their required level of assurance. || No provision for assurance | ||
| + | |- | ||
| + | | 5|| Proof-based || Enable DID subjects to provide cryptographic proof when interacting with other entities. || all they can do is sign assertions, no other proof in this spec | ||
| + | |- | ||
| + | | 6 || Discoverability || Make it possible for entities to discover DIDs for other entities to learn more about or interact with those entities. || Only if universal resolver is deployed. Even then the did method may not convey the information needed to know if the did can be supported, eg did:web and did:indy. | ||
| + | |- | ||
| + | | 7|| Interoperability|| Use interoperable standards so DID infrastructure can make use of existing tools and software libraries designed for interoperability. || where existing only means libraries written specifically to support DID only | ||
| + | |- | ||
| + | | 8 || Portability || Be system and network-independent and enable entities to use their digital identifiers with any system that supports DIDs and DID methods. || Only at sites that support their chosen method and it looks like there will be several hundred methods which this is deployed. | ||
| + | |- | ||
| + | | 9 || Simplicity || Favor a reduced set of simple features to make the technology easier to understand, implement, and deploy. || Not even close | ||
| + | |- | ||
| + | | 10 || Extensibility || Where possible, enable extensibility provided it does not greatly hinder interoperability, portability, or simplicity.|| Possibly true, needs validated | ||
| + | |- | ||
| + | |} | ||
==Problems== | ==Problems== | ||
* The big problem is [[Trust]] where there are no standards or examples of any trust without a history of trusted behavior. | * The big problem is [[Trust]] where there are no standards or examples of any trust without a history of trusted behavior. | ||
| − | * Proof of Persistent Identity must be provided. This can be little more than the inclusion of a public key in a | + | * The plane for a dozen methods has ballooned (2024) into 184 methods, many of which are not longer maintained at all. Several solutions have reverted to centralized methods to avoid collisions.<ref>Trust Over IP, ''Announcing Public Review of the did:webs Method Specification'' https://trustoverip.org/news/2023/12/15/announcing-public-review-of-the-didwebs-method-specification/</ref> |
| + | * Proof of Persistent Identity must be provided. This can be little more than the inclusion of a public key in a block chain, but that cannot provide any [[Assurance]] of protection of the [[Credential]]. | ||
| + | * DID are designed to be tied to a did method (e.g. Sovrin) which means that a life-long ID requires life-long methods with no means to migrate, even when the method dies out or is proven defective. | ||
| + | * [[Assurance]] is mentioned only one time in the DID core spec; as a goal. It is not further defined. | ||
| + | * Privacy Considerations have eliminated all information about the DID except the public key. That means that it is not possible to determine if the subject is a natural person. "The group is attempting to minimize the information in a DID Document to avoid privacy laws kicking in to protect an individual. The group has achieved consensus on the above." quote Manu Sporny in the comments to the document mark-up. (2020-12-08) | ||
| + | * Original comment that "DIDs are designed to come with all sorts of attributes and service points of that particular user. It is highly unlikely that this can be accomplished without leaking the real identity of the subject of the DID" was reduced to just service endpoint by 2020-12. The upshot of the change is that the did cannot even say that the subject is coved by privacy regulations since no indication that the user is a natural person is permitted. | ||
==Solutions== | ==Solutions== | ||
| − | *In | + | *In wiki for the IAP ([[Identifier or Attribute Provider]]) supplies the contents of a [[Data Category]] only when that category has [[User Consent]]. To get all of those categories that the [[Relying Party]] requires, the request needs to go to a [[User Agent]] that is able to release the data held across many providers, some of the [[Thousand Points of Light]] that apply to the real-world [[User]], but only those appropriate for the [[Relying Party]] request are enabled by the user. |
*The [[Hundred Points of Light]] serve as a metaphor for the [[Distributed ID]]. | *The [[Hundred Points of Light]] serve as a metaphor for the [[Distributed ID]]. | ||
==References== | ==References== | ||
| + | <references /> | ||
| + | ===Other Material=== | ||
#[https://cloudblogs.microsoft.com/enterprisemobility/2018/02/12/decentralized-digital-identities-and-blockchain-the-future-as-we-see-it/ Decentralized Digital Identities and Blockchain] perspective from Microsoft | #[https://cloudblogs.microsoft.com/enterprisemobility/2018/02/12/decentralized-digital-identities-and-blockchain-the-future-as-we-see-it/ Decentralized Digital Identities and Blockchain] perspective from Microsoft | ||
| − | + | #[https://w3c.github.io/did-core/ Decentralized Identifiers (DIDs) v1.0] Core Data Model and Syntaxes <blockquote>Decentralized identifiers (DIDs) are a new type of identifier to provide verifiable, decentralized digital identity. These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to a DID document allowing trustable interactions with that subject. DID documents are simple documents describing how to use that specific DID. Each DID document can express cryptographic material, verification methods, or service endpoints, which provide a set of mechanisms enabling a DID controller to prove control of the DID. Service endpoints enable trusted interactions with the DID subject.</blockquote> | |
[[Category:Glossary]] | [[Category:Glossary]] | ||
[[Category:Authentication]] | [[Category:Authentication]] | ||
| − | [[Category: | + | [[Category:Identifier]] |
Latest revision as of 17:57, 25 October 2024
Full Title or Meme
A means to distribute the sources of Identifiers and Attributes while giving more choice to Users.
Context
Every one knows the problem with identities on the internet. They are not under the control of users, who are extremely interested in their own Identity and want their own Privacy.
- Decentralized ID (DID) is a somewhat different concept in that it envisions an Identifier which is crated by the user, and could serve as a basis for a Distributed ID, but does not address the relationship to other Identifiers.
- The current paradigm in open identity is for each conforming Relying Party to provide a list of Identifier or Attribute Providers that the User could chose from to allow access.
- In this model it was up to the Relying Party to establish a link and share a secret with the Identifier or Attribute Provider in advance of any transactions.
- It also required the user to pre-register with one or more of those providers, typically one of the big social sites, like: Google, Microsoft or Facebook.
- The current most common protocol for some sort of a Distributed Identity was OpenID Connect which included Self-issued Identifier, but that feature of OpenID Connect had not been deployed in 2018.
The following evaluation is based on the goals as listed in the spec.
| # | Goal | Description in draft of 2020-01-22 | Status |
| 1 | Decentralization | Eliminate the requirement for centralized authorities or single point failure in identifier management, including the registration of globally unique identifiers, public verification keys, service endpoints, and other metadata. | Spec does not achieve this |
| 2 | Control | Give entities, both human and non-human, the power to directly control their digital identifiers without the need to rely on external authorities. | Some authority needs to validate user agent code. There appears to be not reason to allow untrusted connections on the web, that is HTTPS which depends on identifier of the web site. |
| 3 | Privacy | Enable entities to control the privacy of their information, including minimal, selective, and progressive disclosure of attributes or other data. | Originally not even compliant with GDPR See update in problems below. |
| 4 | Security | Enable sufficient security for relying parties to depend on DID documents for their required level of assurance. | No provision for assurance |
| 5 | Proof-based | Enable DID subjects to provide cryptographic proof when interacting with other entities. | all they can do is sign assertions, no other proof in this spec |
| 6 | Discoverability | Make it possible for entities to discover DIDs for other entities to learn more about or interact with those entities. | Only if universal resolver is deployed. Even then the did method may not convey the information needed to know if the did can be supported, eg did:web and did:indy. |
| 7 | Interoperability | Use interoperable standards so DID infrastructure can make use of existing tools and software libraries designed for interoperability. | where existing only means libraries written specifically to support DID only |
| 8 | Portability | Be system and network-independent and enable entities to use their digital identifiers with any system that supports DIDs and DID methods. | Only at sites that support their chosen method and it looks like there will be several hundred methods which this is deployed. |
| 9 | Simplicity | Favor a reduced set of simple features to make the technology easier to understand, implement, and deploy. | Not even close |
| 10 | Extensibility | Where possible, enable extensibility provided it does not greatly hinder interoperability, portability, or simplicity. | Possibly true, needs validated |
Problems
- The big problem is Trust where there are no standards or examples of any trust without a history of trusted behavior.
- The plane for a dozen methods has ballooned (2024) into 184 methods, many of which are not longer maintained at all. Several solutions have reverted to centralized methods to avoid collisions.[1]
- Proof of Persistent Identity must be provided. This can be little more than the inclusion of a public key in a block chain, but that cannot provide any Assurance of protection of the Credential.
- DID are designed to be tied to a did method (e.g. Sovrin) which means that a life-long ID requires life-long methods with no means to migrate, even when the method dies out or is proven defective.
- Assurance is mentioned only one time in the DID core spec; as a goal. It is not further defined.
- Privacy Considerations have eliminated all information about the DID except the public key. That means that it is not possible to determine if the subject is a natural person. "The group is attempting to minimize the information in a DID Document to avoid privacy laws kicking in to protect an individual. The group has achieved consensus on the above." quote Manu Sporny in the comments to the document mark-up. (2020-12-08)
- Original comment that "DIDs are designed to come with all sorts of attributes and service points of that particular user. It is highly unlikely that this can be accomplished without leaking the real identity of the subject of the DID" was reduced to just service endpoint by 2020-12. The upshot of the change is that the did cannot even say that the subject is coved by privacy regulations since no indication that the user is a natural person is permitted.
Solutions
- In wiki for the IAP (Identifier or Attribute Provider) supplies the contents of a Data Category only when that category has User Consent. To get all of those categories that the Relying Party requires, the request needs to go to a User Agent that is able to release the data held across many providers, some of the Thousand Points of Light that apply to the real-world User, but only those appropriate for the Relying Party request are enabled by the user.
- The Hundred Points of Light serve as a metaphor for the Distributed ID.
References
- ↑ Trust Over IP, Announcing Public Review of the did:webs Method Specification https://trustoverip.org/news/2023/12/15/announcing-public-review-of-the-didwebs-method-specification/
Other Material
- Decentralized Digital Identities and Blockchain perspective from Microsoft
- Decentralized Identifiers (DIDs) v1.0 Core Data Model and Syntaxes
Decentralized identifiers (DIDs) are a new type of identifier to provide verifiable, decentralized digital identity. These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to a DID document allowing trustable interactions with that subject. DID documents are simple documents describing how to use that specific DID. Each DID document can express cryptographic material, verification methods, or service endpoints, which provide a set of mechanisms enabling a DID controller to prove control of the DID. Service endpoints enable trusted interactions with the DID subject.
