codexproof

glossary / Self-certifying names

names that carry the means of their own verification - you can check that data matches its name, or that a key owns its name, without asking any authority.

content addressingdid keyanchor
Self-certifying names - The identity half of self-certification: derive the key from the name, ask nobody

The identity half of self-certification: derive the key from the name, ask nobody.

Etymology and backstory

the term comes from the Self-certifying File System (SFS, David Mazieres and colleagues, late 1990s), where a server's address embedded the hash of its public key, so connecting and authenticating needed no certificate authority. The idea generalizes in two directions: hash-based names self-certify content (cids), and key-based names self-certify identity (did:key).

Ecosystem

Tor onion addresses (derived from the service key), IPFS peer IDs, NDN's signed data with schematized trust, the did:key method - all descendants. The common bargain: you gain freedom from registries and certificate authorities, and you give up the ability to change the key while keeping the name.

In codexproof

both directions run at once. Content self-certifies via cid; domains self-certify via did:key anchors. That is why verification works offline against consumer-chosen anchors with no CA anywhere - and it is also exactly why anchors cannot rotate (the Q19 concession): the name IS the key, so a new key is definitionally a new name.

---

"Self-certifying names delete the certificate authority from the trust story - the price is that identity and key become one object, which is our number-one named limitation."

All terms · Questions & answers · The verifier