DIDs
Decentralized Identities and their methods
Based on W3C’s Decentralized Identifiers specs, Terminal 3 supports the creation and use of decentralized identifiers (DIDs).
What is a Decentralized Identifier (DID)?
DIDs are identifiers that enable verifiable, decentralized digital identities. A DID refers to any subject (e.g. a person, group, organization, abstract entity, etc.) as determined by the controller of the DID.
Specifically, DIDs are URIs (unique digital addresses) that associate a DID subject with a DID document allowing trustable interactions associated with that subject. Similar to a URL, when you resolve a DID, you receive a DID document in JSON, JSON-LD, or similar format.
A simple DID example
A DID is a simple unique text string consisting of three parts:
- the
did
URI scheme identifier; - the identifier for the DID method; and
- the DID method-specific identifier.
The example DID above resolves to a DID document.
Multiple DIDs
A subject may have as many DIDs as they want for different use cases, such as:
- a DID for educational certificates; or
- a DID for verified identity / KYC documents; or
- a DID for online gaming accounts.
What is a DID Document?
A DID document contains information associated with the DID, such as ways to cryptographically authenticate a DID controller.
DID Methods
A DID method (and its spec) defines the precise operations by which DIDs and DID documents are created, resolved, updated, and deactivated.
There are currently more than 150 DID methods out there, which can be categorized into 4 main types based on their storage method:
- Centralized: relies on a Web2 server
- Blockchain-based: the “original” DID method involving a blockchain
- Hybrid (Blockchain + IPFS): uses decentralized storage (e.g. IPFS) to store its documents
- Static: no data registry is required; can be created and resolved by encoding/decoding data directly.
💡 Terminal 3 currently supports Static and Hybrid DIDs.
Centralized | Blockchain-based | Hybrid | Static | |
---|---|---|---|---|
Privacy | low | high | high | medium |
Self-Sovereign? | no | yes | yes | yes |
Data Registry Required? | yes | yes | yes | no |
(web2 server) | yes | |||
(Blockchain) | yes | yes | ||
(L2 storage) | yes | |||
Decentralized? | no | yes | yes | yes |
Complexity | simple | complex | medium | simple |
Transaction Fee Required? | no | yes | yes | no |
(when updating) | yes | |||
Mutable? | yes | no | no | no |
Supported Operations | create read update delete | create read update delete | create read update delete | create read |
Example | did:web | did:ethr did:btcr did:dock | did:3 did:ion did:elem | did:key did:pkh |
DID System Architecture
Generic DID Architecture
High-level T3 DID System
Static DID (did:key
)
Hybrid DID
- DID Adapter: wrapper for DID Resolver and provides an API/SDK for T3 users or enterprises to integrate with.
- DID Resolver: resolves DID Documents; compatible with the DID Resolver spec.
- DID Controller: to create, update and delete DID documents from DID Registry Contract.
- DID Registry: to upload DID Document to IPFS and call DID Registry Contract to map the DID with the IPFS hash address.****
- DID Registry Contract: to deploy and interact with the Blockchain (e.g. Ethereum)
- setIPFSToDID
- getIPFSFromDID
- IPFS: to store the DID Document.
- Blockchain: to anchor the DID with its corresponding IPFS hash.