Decentralized Identifiers (DIDs)

What They Are

A Decentralized Identifier (DID) is a globally unique identifier that you create and control yourself — no registration authority required. Unlike an email address (controlled by your email provider) or a social media handle (controlled by the platform), a DID is cryptographically yours. You prove you own it by demonstrating control of the associated private keys.

DIDs are a W3C standard. They look like this:

did:webvh:QmExample123:example.com

Every DID resolves to a DID Document — a JSON file that lists your public keys, how to communicate with you, and what services you offer. Anyone can look up your DID Document and verify that messages or credentials from you are authentic.

Why They Matter for OpenVTC

The entire OpenVTC ecosystem is built on DIDs. Every participant — every person, every service, every community — has a DID. These identifiers are the nodes in the Decentralized Trust Graph. When someone issues a Verifiable Credential to you, it’s addressed from their DID to yours. When you send a DIDComm message, it’s encrypted from your DID’s keys to the recipient’s DID’s keys.

DID Methods in the Ecosystem

A “DID method” defines how a particular type of DID is created, resolved, and updated. The ecosystem uses several:

did:webvh (Primary)

did:webvh is the primary DID method for the ecosystem. It extends did:web (which simply hosts a DID document at a URL) with a verifiable history — a cryptographically signed log of every change to the DID document. This gives you:

Portability — you can move your DID to a new domain without losing your identity, thanks to a Self-Certifying Identifier (SCID)
Key rotation — you can update your keys while proving continuity of identity
Pre-rotation — you can commit to your next key before you need it, preventing key compromise from hijacking your identity
Witness proofs — third parties can attest to the integrity of your DID history

did:key (Simple)

Used for simple, self-contained identifiers — typically for credential signing keys that don’t need the full lifecycle management of did:webvh. A did:key is just a public key encoded as an identifier. No resolution infrastructure needed.

did:peer (Private)

Used for Relationship DIDs (R-DIDs) — private, pairwise identifiers created for individual relationships. When you connect with someone, you create a unique did:peer for that relationship so your primary Persona DID isn’t exposed in every interaction.

DID Type Taxonomy

The DTG specification defines a formal taxonomy of DID types, each serving a specific role. See DID Types in the DTG for the full reference. In brief:

C-DID — Community DID (identifies a VTC or VTN)
M-DID — Member DID (identifies an individual within a community)
R-DID — Relationship DID (unique per relationship, for privacy)
P-DID — Persona DID (for selective persona disclosure)
W-DID — Witness DID (for witness attestations)

How DID Resolution Works

When an application encounters a DID, it needs to resolve it — look up the DID Document to get the public keys and service endpoints. The Affinidi TDK provides a high-performance DID resolver that:

Supports multiple DID methods (webvh, key, peer, etc.)
Caches resolved documents locally (claiming 250k+ resolutions/sec from cache)
Validates the cryptographic integrity of did:webvh history logs
Plugs into the didwebvh-rs library for webvh-specific resolution

The Relationship Between DIDs and Keys

In the OpenVTC ecosystem, all keys derive from a single BIP-39 mnemonic seed via BIP-32 derivation. This means one backup phrase protects your entire identity. The VTA manages this derivation, creating separate key contexts for different purposes:

Persona keys — your primary identity keys
DID management keys — for updating your did:webvh document
Relationship keys — unique keys for each relationship you establish
Application keys — for specific services and integrations

OpenVTC Wiki

Explorer