codexproof

glossary / did:key

the simplest W3C Decentralized Identifier method - the identifier IS the public key, encoded into a string, so identity needs no registry, no ledger, and no lookup, and verification works offline forever.

self certifying namesed25519x509 and webpkiverifiable credentials
did:key - The identifier dissected: scheme, method, codec prefix, and the key itself

The identifier dissected: scheme, method, codec prefix, and the key itself.

Etymology and backstory

DIDs grew out of the self-sovereign identity movement and became a W3C Recommendation (DID Core 1.0) in 2022. Most DID methods anchor identifiers somewhere - did:web in DNS and HTTPS, others in ledgers. did:key is the degenerate, beautiful case: multibase-encode the public key bytes with a codec prefix, prepend did:key:, done. The z6Mk prefix Eric sees on anchors is the multibase-base58 signature of an Ed25519 public key.

Ecosystem

verifiable credentials pilots, DIDComm messaging, test and offline scenarios across the SSI world - anywhere you want identity without infrastructure.

In codexproof

every domain anchor is a did:key. This buys the paper its no-CA, offline-verification story and costs it key rotation - the name is the key, so a new key is a new identity (the Q19 concession, named openly as the number-one open problem).

"did:key is identity with the infrastructure amputated - which is exactly the property you want at the trust root, and exactly why the root can never rotate."
References: W3C, "Decentralized Identifiers (DIDs) v1.0," W3C Recommendation (2022). Longley, Sporny, et al., "The did:key Method," W3C CCG draft. Mazieres and Kaashoek, "Escaping the Evils of Centralized Control with self-certifying pathnames," SIGOPS European Workshop (1998) - the ancestral idea.

All terms · Questions & answers · The verifier