Skip to content
Switch branches/tags
Go to file
Cannot retrieve contributors at this time

DIDs In DPKI (Decentralized Public-key Infrastructure)

This document seeks to act as a starting point to bridge the two worlds of DPKI (which appeared in the first RWOT) with DIDs (which appeared at the second RWOT).

Author: Greg Slepak (twitter, mastodon)


Remember DPKI?!

A quick reminder for those who don't:

  • DPKI stands for Decentralized Public-key Infrastructure
  • DPKI seeks to serve as an improved alternative/replacement for X.509 (that thing securing today's Internet)
  • DPKI changes the web's security model from 1000s of single-points-of-failure to decentralized consensus groups that create namespaces (sorta like what blockchains do!)
  • DPKI is not a blockchain — it's a protocol for securely accessing blockchains and similar decentralized consensus systems
  • DPKI has Top-Level Domains (TLDs) representing different blockchains (e.g. .eth, .bit, .id etc.)

For an overview of DIDs read the DID Primer.


We're kinda making this up as we go along, so there is no fixed timeline, but so far this is how things are turning out to be:

DPKI Overview (RWOT1)
+-> Requirements for DIDs (RWOT2)
    +-> DID Data Model and Generic Syntax Draft 1 (RWOT3)
        +-> Decentralized Identifiers v1.0 (RWOT6)
            +-> ??? (RWOT7)


A DID key looks like this:


A specific example might look something like this (taken from BTCR DID Resolver Specification):


Obviously this is not useful (by itself) for dealing with human-readable TLDs.

What are we trying to do here, ultimately?

We are trying to Square Zooko's Triangle:

         /  \
        /    \
       /      \
Secure          Human-readable

So far DIDs give us Secure <-----> Decentralized.

We are still missing Human-readable.

That's where TLDs and Namespaces come in.

TLDs and Namespaces

But before we can talk about TLDs and Namespaces, we need to address a philosophical "debate" ("question"?) within the DID ethos.

Are DIDs Human-readable?

The answer to this question is not clear.

Some have argued that DIDs should be "unique identifiers that last a lifetime". Meaning, no, they should not be human readable.

Instead they should act like a UUID that you can point other things to.

Still others say there's no reason they can't be unique and human readable.

So a DID could look like this:


Or it could look like this:


One thing is clear: if a DID isn't human-readable, you are still going to need a human-readable identifier within a secure namespace to find it.

Why? Why can't you, for example, take the GNUnet approach (e.g. "linked local names") and create an inconsistent decentralized world, where everyone has their own personal address book, and they somehow discover and save a non-human-readable identifier to a local, human-readable contact card?

Well, they certainly can do that, but that is not what DPKI is about.

DPKI is about global identifiers, not local identifiers.

DPKI has to re-create the usual experience that we're used to, where you type in an easily memorized human-readable term, like, and no matter where you are in the world, no matter what device you're using, you will find Apple's homepage with that tiny, easily memorized identifier.

This is important not only for visiting websites, it's also important for making other protocols, like email, secure.

So whether or not ALL DIDs are human-readable is irrelevant to DPKI — In DPKI, DIDs Are Human-readable.

In other words, identifiers in DPKI have these properties:

  • They exist in a namespace secured through decentralized consensus, e.g. a blockchain (see also, DCS Theorem)
  • They are human-readable
  • They are updateable
  • They can expire
  • They are looked up through a secure lookup mechanism that does not have a SPOF (single-point-of-failure)

Past Discussion and Related Topics

Next Steps

The RWOT community needs to come up with a protocol that fulfills the DPKI goals as stated in the DPKI overview document (with amendments one and two).

We need to create a protocol that takes a normal-looking domain, for example:


Look up bitcoin.btc in a secure, decentralized manner through the Bitcoin blockchain (or Ethereum if the TLD is .ens), do any additional lookups, and return two things:

  1. An IP address to the server that's hosting that domain
  2. A list of hashes representing valid public keys for that domain

Then it's up to the browser to connect to the IP address and retrieve the webpage.