Welcome to DIDs 201

In our last post, we covered what DIDs are and more importantly why DIDs exist. Now it’s time to diver a little deeper into how they actually work. An identifier, as we know, is not magical by itself, but DIDs are not just identifiers they also have something called a DID Document. The DID Document is where the power of a DID truly resides.

What is a DID Document?

A DID Document (DDO) is, you guessed it, a document! An identifier by itself can only tell someone so much. Just like a name or an email can’t really tell you who someone is really just how to find them in some system. Now, DID Documents shouldn’t be confused with profiles (or Data Backpacks in the case of Disco).

DID Documents are the thing that sits between an identifier and all of the other things that make up an identity. For that reason, think of a DID Document as a bit of a directory and manual. It’s like a directory because a DID Document can contain what are called “service endpoints”. These endpoints are locations on the internet that other systems can go to find out more information about whom or what the DID refers to. These endpoints could point you to a profile, online storage, or the addresses to receive cryptocurrencies or messages. DID Documents partially are manual because DID Documents can tell others the rules for interacting with your DID. A DID can list other cryptographic keys that it controls and uses for certain cryptographic operations. This means that with one public address, someone can resolve that address to a DID Document to find a bunch of other keys and service endpoints that the person or thing in question also controls. Additionally, the way a DID Document gets updated, that is the way it gets keys and endpoints added to it or removed from it is governed by the DID Method.

The DID Document also allows DIDs to deliver on the promise of persistence. This is because a DID Document has a field that denotes the “controller” of the DID Document. This controller is a public cryptographic address or key that acts as the ultimate authority for signing off on updates to a DID Document. Nobody should trust information in a DID Document that wasn’t cryptographically signed by the controller. This means that the controller can change while keeping their DID the same.

This allows us to do “key rotation”. You can change to a new private key without abandoning your public identifier. This is kind of like being able to change the locks on your house without having to change your physical address. Most of the time when you first create your DID, the controller and the subject (the entity that the DID actually refers to) is the same public address. But after a key rotation, the controller would be different but the subject would remain the same, and that is one of the powerful features of DIDs.

The Different Types of DIDs

There are over 100 types of DIDs. These “types” are defined by different DID Methods which we talked about a bit earlier. And while we can’t be sure about what novel types of methods might arise in the future, the current methods fall into 5 different categories:

• Ledger Based DIDs: These are DIDs that based on blockchains (or decentralized ledgers as they are sometimes called). This means that your DID is either added to the ledger or is itself a blockchain address (as is the case with methods like DID:ETHR). Additionally, updates to the DID Document are tracked using the ledger. This has the advantage of using the security and consensus of the blockchain but can increase the costs of making updates and in some cases decrease the privacy of the user.

• Decentralized Storage Based DIDs: These are very similar to Ledger based DIDs except that they use a decentralized storage network like IPFS or Ceramic (as is the case with Disco) to store a DID Document. In most cases this means that even if you have a crypto wallet and blockchain address you will need to generate a new identifier to be the unique identifier in your DID that is specific to that storage network. The upside to these DID Methods is that they are very cheap to update, but can theoretically have security or availability issues depending on the storage network’s performance.

• Peer DIDs: These are a specific type of DID that is generated and known only between a certain set of entities. They are particular interesting in the case of 1 to 1 relationships.

• Static DIDs: These are essentially pseudo-DIDs. This is because static DIDs do not make use of DID Documents. This means they cannot perform many of the functions DIDs were created to perform. Static DIDs allow regular identifiers, like blockchain addresses to act like DIDs in a DID based system without needing to do all of the extra complicated stuff. Static DIDs are useful mostly when you are in need of a temporary, ephemeral identity that you don’t intend to use long term.

• Alternative DIDs: This is a catch all for other types of DID Methods. The most common Alternative DID is DID:WEB. This allows a Web2 based identifier, like a a Facebook ID or a domain name to act like a DID. However, these DID types falls short on many of the principles that DIDs aim to adhere to, namely Decentralization. These methods are likely only appropriate in narrow contexts.

Conclusion

Ok, that was a lot, but you made it. You should now be confident using the term DID in a Tweet. There are still a ton of other awesome topics and details related to DIDs  and if you would like to go even deeper you are encouraged to check out https://www.w3.org/TR/did-core/. If you’d like to get started with your own DID visit www.disco.xyz and for all the builders, you can find the all the technical details at https://docs.disco.xyz/. Class dismissed!

Jonny Howle

Co-Founder / Head of Strategy

@jonnyhowle

Kindly send any feedback to ask@disco.xyz or sign up for a 1:1 feedback session here.