Decentralized Identifier (DID)
A DID is the foundational building block for decentralized identity. Below is a high-level overview of the DID architecture.
There are six pieces to the architecture diagram above:
- DID URL: How a DID can be looked up (resolved).
- DID: The actual ID scheme.
- DID Document: Stores important information like DID history, public key(s), and other metadata describing the DID subject.
- DID Subject: Who the DID is about.
- DID Controller: Who has control of the DID.
- Verifiable Data Registry: Where the information is stored.
DID
A DID is a three part system: scheme, method, and specific string.
did:example:123456abcdef
did: scheme: Not much more to say here.example: method: The DID method is a formal document that sets out all of the rules for how the DID is implemented. It would set things like, what VDR is being used, how DIDs are created, updated, resolved, and deactivated. Check the DID Methods page for more.1231456abcdef: specific string: How this string is constructed will be set in the DID method. However, this string must be unique. It is kind of like a username but usually randomly generated.
| Category | Description |
|---|---|
| Ledger based DIDs | Original DID category where a blockchain serves as a registry with transactions written to store info. |
| Ledger Middleware DIDs | An improvement with a storage layer in between the user and the blockchain. Only a hash of the stored information is saved on the DLT. |
| Peer DIDs | There is no globally shared registration. Instead a DID in a peer-to-peer fashion. |
| Static DIDs | These DIDs are created and resolvable but can not be updated or deactivated. They tend to be far more simple. |
| Alternative DIDs | There are a variety of other methods that are being developed that do not currently meet the other four categories. |