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:
  1. the did URI scheme identifier;
  2. the identifier for the DID method; and
  3. the DID method-specific identifier.
DID-method specifier 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. 
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
}

​
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.
CentralizedBlockchain-basedHybridStatic
Privacylowhighhighmedium
Self-Sovereign?noyesyesyes
Data Registry Required?yesyesyesno
(web2 server)yes
(Blockchain)yesyes
(L2 storage)yes
Decentralized?noyesyesyes
Complexitysimplecomplexmediumsimple
Transaction Fee Required?noyesyesno
(when updating)yes
Mutable?yesnonono
Supported Operationscreate
read
update
delete		create
read
update
delete		create
read
update
delete		create
read
Exampledid:webdid:ethr
did:btcr
did:dock		did:3
did:ion
did:elem		did:key
did:pkh

​
DID System Architecture

​
Generic DID Architecture

Generic DID architecture

​
High-level T3 DID System

High level T3 DID system

​
Static DID (did:key)

T3 DID flow

​
Hybrid DID

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.