Difference between revisions of "Distributed Identity"
From MgmtWiki
(→Context) |
(→Context) |
||
| Line 6: | Line 6: | ||
** 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 | + | * 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. | * Now other organizations believe that they can succeed where the OpenID foundation failed. | ||
Revision as of 09:33, 6 August 2018
Full Title or Meme
A means to distribute the sources of Identifiers and Attributes while giving more choice to Users.
Context
- 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 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, which cannot have 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) supplies only the Data Category that 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
