Conventional Identity Management Architectures are based on centralized authorities such as corporate Directory Services, Certificate Authorities, or domain name registries. From the standpoint of cryptographic trust verification, each of these centralized authorities serves as its own Trust Anchor. To make Identity Management Architectures work across these systems requires implementing Federated Identity Management.
The emergence of Distributed Ledger Technology (DLT), sometimes referred to as blockchain technology, provides the opportunity to implement fully decentralized identity management. In this ecosystem, all participants with identities (called identity owners) share a common Trust Anchor in the form of a globally distributed ledger (or a decentralized P2P network that provides similar capabilities).
Each identity owner can be identified on a ledger with a key-value pair. The index key is a Decentralized Identifier and the value is its associated DID descriptor object. Together these form a DID record. Each DID record is cryptographically secured by Private Keys under the control of an identity owner (in the case of an owner-managed identity) or a guardian (in the case of a guardian-managed identity). A corresponding Public Key is published in the DID descriptor object using a key description. A DID descriptor object may also contain a set of service endpoints for interacting with the identity owner. Following the dictums of Privacy by Design, each identity owner may have as many DID records as necessary to respect the identity owner’s desired separation of identities, personas, and contexts.
To use a Decentralized Identifier with a particular distributed ledger or network requires defining a DID method specification.
This design eliminates dependence on centralized registries for identifiers as well as centralized certificate authorities for Key Management. With DID records on a distributed ledger, each identity owner may serve as its own Trust Anchor—an architecture referred to as DPKI (Decentralized PKI).
Each Decentralized Identifier uses a specific Decentralized Identifier method, defined in a separate DID method specification, to define how the Decentralized Identifier is registered, resolved, updated, and revoked on a specific Distributed Ledger Technology or network.
Motivations for Decentralized Identifiers#The growing need for a Decentralized Identifier has produced three specific requirements for a new type of URI that fits within the URI/URL/URN architecture, albeit in a less than traditional way:
- A URI that is persistent like a URN yet can be resolved or de-referenced to locate a resource like a URL. In essence, a DID is a URI that serves both functions.
- A URI that does not require a centralized authority to register, resolve, update, or revoke. The overwhelming majority of URIs today are based on DNS names or IP addresses that depend on centralized authorities for registration and ultimate control. DIDs can be created and managed without any such authority.
- A URI whose ownership and associated metadata, including public keys, can be cryptographically verified. Control of DIDs and DDOs leverages the same public Key/private Key cryptography as Distributed Ledger Technology.
More Information#There might be more information for this subject on one of the following:
- DID descriptor objects
- DID method
- DID record
- Hyperledger Indy
- JSON-LD Examples
- Web Blog_blogentry_011216_1
- [#1] - DID (Decentralized Identifier) Data Model and Generic Syntax 1.0 - based on information obtained 2016-12-01-