Difference between revisions of "Decentralized ID"

From MgmtWiki
Jump to: navigation, search
(Miscellaneous References)
(Solutions)
Line 17: Line 17:
  
 
==Solutions==
 
==Solutions==
* The W3C has established a community group to establish the consensus needed to crate a working group that would then propose a [https://w3c-ccg.github.io/did-spec/ draft standard for the DID - Decentralized ID], and also a [[Verifiable Claim]]s WG.
+
* The W3C has established a credential community group (CCG) to establish the consensus needed to crate a working group that would then propose a [https://w3c-ccg.github.io/did-spec/ draft standard for the DID - Decentralized ID], and also a [[Verifiable Claim]]s WG.
*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]].
+
* [[Verified Claim]] is one of the work efforts of the CCG.
 
*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 [[Hundred Points of Light]] that apply to the real-world [[User]], but only those appropriate for the [[Relying Party]] request are enabled by the user.
 
*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 [[Hundred Points of Light]] that apply to the real-world [[User]], but only those appropriate for the [[Relying Party]] request are enabled by the user.
  

Revision as of 20:34, 18 January 2019

Full Title or Meme

The DID is a URL that points to a DID document and can server as an Identifier that is under the control of a Subject.

Context

  • Distributed ID is a somewhat different concept in that it envisions an identity which is broken into may pieces that are hosted by many different authorities and only brought together in a Relying Party upon User Consent.
  • 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 concept never succeeded in the marketplace. It could certainly be revived in the context of a Decentralized ID.
  • Now other organizations believe that they can succeed where the OpenID foundation failed.
  • 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.

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 DID Method Registry has been created to track the methods that implement the DID spec. There seem to be no particular criteria for a method to be accepted other than a willingness of the method's authors to submit the method as compliant.

Self-sovereign identities seem to be the answer to all parties' concerns. [2] The only problem with it that I can see is that no one seems to know exactly what it is or how it might work. MIT has started an open source effort to build something[3] but no one seems to know what.

References

  1. BELLCORE SPINS OFF NEW COMPANY TO OFFER DIGITAL NOTARY (TM)(SM) SERVICE http://seclists.org/interesting-people/1994/Mar/100
  2. Ian Glazer, Why self-sovereign identity will get adopted (and it’s not the reason you probably want) 2018-06-15 https://www.tuesdaynight.org/2018/06/15/why-self-sovereign-identity-will-get-adopted-and-its-not-the-reason-you-probably-want/
  3. Github, Developing General Principles for Sovereign Identity. https://github.com/mitmedialab/SovereignIdentityPrinciples

Miscellaneous References