Distributed ID

From MgmtWiki
Revision as of 13:17, 2 February 2020 by Tom (talk | contribs) (Context)

Jump to: navigation, search

Full Title or Meme

A means to distribute the sources of Identifiers and Attributes while giving more choice to Users.


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 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
3 Privacy Enable entities to control the privacy of their information, including minimal, selective, and progressive disclosure of attributes or other data. not even compliant with GDPR
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
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
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


  • 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 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.
  • 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 user (subject of the DID.)
  • Assurance is mentioned only one time in the DID core spec; as a goal. It is not further defined.



  1. Decentralized Digital Identities and Blockchain perspective from Microsoft
  2. 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.