The Decentralized Identifiers (DIDs) are globally unique identifiers designed to enable individuals and organizations to generate self-sovereign identifiers using systems they trust, and to prove control of those identifiers (authenticate) using cryptographic proofs (for example, digital signatures, privacy-preserving biometric protocols, and so on).
A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. A DID Architecture is depicted in the figure below:
DIDs are typically used between DID Controllers and relying parties (also called verifiers). The following groups of functionalities are possible with DIDs:
- Create features – provisioning DIDs and corresponding DID documents (done exclusively by the DID controller and according to DID method specification)
- Delete features – deleting DID material, performed exclusively by the DID controller
- Update features – the features for updating DID documents, such as rotating keys, modifying service endpoints, migration and recovery, performed by the DID controller
- “Use” features – enable presentation, authentication and cryptographic signing by the controller, and verification and auditing by the relying party (the verifier)
- “Read” features – corresponding to DID resolution and dereferencing, by definition performed by the relying party
An overview of DID actions is depicted in the following figure:
