Difference between revisions of "Distributed Identity"
From MgmtWiki
(Created page with "==Full Title or Meme== A collection of Authentication results or Attribute Validations presented to an Authorization Service to control access to a resource, t...") |
(→Context) |
||
(26 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
− | A | + | A means to distribute the sources of [[Identifier]]s and [[Attribute]]s while giving more choice to [[User]]s. |
==Context== | ==Context== | ||
− | [[ | + | * [[Distributed ID]] is a particular implementation of [[Distributed Identity]] that was still in development in 2018. |
+ | * [[Decentralized ID]] is a somewhat different concept in that it envisions an identity which is centralized with the user rather than with a central authority. | ||
+ | * 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. | ||
+ | ** 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. | ||
+ | * Interestingly [https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.4.0/security/cics/idprop_intro.html IBM has offered support for Distributed Identity] in their CICS for several generations now. This is similar to the federated identity supported by [https://en.wikipedia.org/wiki/Active_Directory_Federation_Services Microsoft ADFS]. | ||
+ | * The current most common protocol for some sort of a [[Distributed Identity]] was [[OpenID Connect]] which included [[Self-issued Identity]], but that concept never succeeded in the marketplace. | ||
+ | * Now other organizations believe that they can succeed where the OpenID foundation failed. | ||
==Problems== | ==Problems== | ||
+ | * The big problem is [[Trust]] where there are no standards or examples of any trust without a history of trusted behavior. | ||
+ | * Beware of time-stamping services posing as trust anchors. Bellcore created such a service in the early 1990 and spun it off into a separate company in 1994.<ref>BELLCORE SPINS OFF NEW COMPANY TO OFFER DIGITAL NOTARY (TM)(SM) SERVICE http://seclists.org/interesting-people/1994/Mar/100</ref> None of these services provide any trust in the contents of the documents. | ||
+ | * Proof of Persistent Identity must be provided. This can be little more than the inclusion of a public key in a blockchain, but that cannot provide any [[Assurance]] of protection of the [[Credential]]. | ||
==Solutions== | ==Solutions== | ||
+ | *The Decentralized Identity Foundation has been created to enable "an open source decentralized identity ecosystem for people, organizations, apps, and devices". The have a list of areas of interest<ref>Decentralized Identity Foundation working groups http://identity.foundation/working-groups</ref> that include block-chain and universal discovery which seem to be diametrically opposite of [[Privacy]] legislation like the [[GDPR]] and [[California Consumer Privacy Act of 2018]]. | ||
+ | *In this wiki the IAP ([[Identifier or Attribute Provider]]) supply 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. | ||
==References== | ==References== | ||
− | |||
[[Category:Glossary]] | [[Category:Glossary]] | ||
+ | [[Category:Identity]] | ||
+ | [[Category:Identifier]] |
Latest revision as of 10:20, 22 December 2018
Full Title or Meme
A means to distribute the sources of Identifiers and Attributes while giving more choice to Users.
Context
- Distributed ID is a particular implementation of Distributed Identity that was still in development in 2018.
- Decentralized ID is a somewhat different concept in that it envisions an identity which is centralized with the user rather than with a central authority.
- 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.
- Interestingly IBM has offered support for Distributed Identity in their CICS for several generations now. This is similar to the federated identity supported by Microsoft ADFS.
- The current most common protocol for some sort of a Distributed Identity was OpenID Connect which included Self-issued Identity, but that concept never succeeded in the marketplace.
- Now other organizations believe that they can succeed where the OpenID foundation failed.
Problems
- The big problem is Trust where there are no standards or examples of any trust without a history of trusted behavior.
- Beware of time-stamping services posing as trust anchors. Bellcore created such a service in the early 1990 and spun it off into a separate company in 1994.[1] None of these services provide any trust in the contents of the documents.
- Proof of Persistent Identity must be provided. This can be little more than the inclusion of a public key in a blockchain, but that cannot provide any Assurance of protection of the Credential.
Solutions
- The Decentralized Identity Foundation has been created to enable "an open source decentralized identity ecosystem for people, organizations, apps, and devices". The have a list of areas of interest[2] that include block-chain and universal discovery which seem to be diametrically opposite of Privacy legislation like the GDPR and California Consumer Privacy Act of 2018.
- In this wiki the IAP (Identifier or Attribute Provider) supply 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.
References
- ↑ BELLCORE SPINS OFF NEW COMPANY TO OFFER DIGITAL NOTARY (TM)(SM) SERVICE http://seclists.org/interesting-people/1994/Mar/100
- ↑ Decentralized Identity Foundation working groups http://identity.foundation/working-groups