Difference between revisions of "Decentralized ID"

Revision as of 09:42, 25 January 2021

Full Title or Meme

The DID is a URL that points to a DID document and can serve as a public key Certificate for an Identifier that is under the control of a Subject.

Context

• The DID is a part of the area now know as Decentralized Identifiers.
• Distributed ID is a somewhat different concept from Decentralized ID 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 new organizations believe that they can succeed where the OpenID foundation and all of the other standards effort have 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.

• The BHAG (big hairy audacious goal) is the user in control, when the user really doesn't want to control their identifiers any more than than they want to program their own computers.

Problems

• The One big problem with the existing solution of relying on social networks is that they control, and can remove, your identifiers at their sole discretion. Or in their own words:
  • Yahoo may, without telling you, immediately cancel or limit your access to your Yahoo accounts, certain Yahoo Services and any associated email addresses...
  • If you violate the letter or spirit of this Statement, or otherwise create risk or possible legal exposure for us, we can stop providing all or part of Facebook to you.
  • We reserve the right to modify or terminate the Service or your access to the Service for any reason, without notice, at any time, and without liability to you [Instagram]
• Another 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.
• Note that proof of persistence does require that the user sign something contemporaneous. If not a document from the provider, it could be a simple as a nonce, or non-repeating integer. Note that this "feature" is not part of the draft of the DID spec available on (2019-01), but it would be part of any secure identity system.
• While the DID spec does not require public ledger solutions (aka blockchain), it is a part of the significant DID methods. That means that all transactions are a matter of public record. Therefore the entirety of the provable assertions by the subject can be acquired by any attacker anywhere in the world. Given what we already know about publicly available information, it is likely that any mildly interested AI could reverse engineer the identity of the subject. So imagine that Bitfury, a technology company in the country of Georgia with access to cheap electric power^[2] decides it is more profitable to track did identifiers for advertisers than mining for bitcoin. If it is possible, it will happen.
• Consider the problems reflected in their standardization effort as shown in Block Chain#Problems.
• Identities on block chains cannot be recovered if the access to the private key used to create the DID is lost.
• The transaction times for block chain reads is on the order of 10s of seconds, the write time is on the order of 10s of minuets. Neither would be acceptable for a web identity.
• The power consumption of a full node on a block chain is way in excess of what a portable device could ever afford on battery power.

Solutions

• The W3C has established a credential group (CG) to establish the consensus needed to propose a draft standard for the DID - Decentralized ID, and also a Verifiable Claims WG.
• Verified Claim is one of the work efforts of the CG.
• 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.
• 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. ^[3] 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^[4] but no one seems to know what.
• Side tree protocol provides a high transaction through-put capability for DIDs.
• The Ion ID is a variant of the DID that is based on the side tree protocol.
• Trusted Identifiers are a variant of the Decentralized ID that enables Identifier Recovery as would be required for many real-world scenarios like Health Care.

Problems from the Solutions

• The did: method defined by the W3C allows infinite extensibility (much like the DNS does) so that is it not possible to decide if a method is supported. For example did:web and did:indy are just pointers to other registries, which could in turn point to yet other registries. Any unlike the DNS, which is handled by a special protocol that is not seen the the application, the did proliferation must be handled by the application.

References

1. ↑ BELLCORE SPINS OFF NEW COMPANY TO OFFER DIGITAL NOTARY (TM)(SM) SERVICE http://seclists.org/interesting-people/1994/Mar/100
2. ↑ Liz Alderman, A Bitcoin Gold Rush in the Caucasus. (2019-01-23) The New York Times p. B1ff
3. ↑ 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/
4. ↑ Github, Developing General Principles for Sovereign Identity. https://github.com/mitmedialab/SovereignIdentityPrinciples

Miscellaneous References

• Phil Windley has created a model based on DIDs and Verified Credential that is very ambitious, but without sufficient detail to make a deployment feasible.
• W3C Workshop on Strong Authentication and Identity (2018-12-10) Location Microsoft Building 27, Redmond, WA had almost no presentations on strong authentication but lots about the DID.
• Use Case 21 and over with proof of presence was the one strong auth presentation given at the strong identity workshop (2018-12-11).
• The DIF web site has a lot of supporting documentation for the DID.