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:

1. the did URI scheme identifier;
2. the identifier for the DID method; and
3. 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.

{
  "@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.

	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.