Get Ready for the Token Sale!

DID 101: a crash course on the next-gen standard for digital identity

11 August 2021 | Digital identity, News

Sophie Dramé-Maigné

Unikname Connect successfully audited by Vaadata

DID. This acronym has been popping up a lot more recently. We have discussed what it should and should not stand for in a previous article. So when we say DID, we refer to a standard from the DIF and W3C that describes a new kind of decentralized identifiers.  According to this standard, a DID is a string of characters made up of three parts separated by colons: a fixed prefix, the DID method, and a method-specific identifier. It can be used to designate pretty much anything. Based on verifiable data registries, i.e. blockchains, DID enable truly decentralized, interoperable, verifiable, discoverable, digital identity. 

DID: an emerging standard

In this article, we will dive into a more technical presentation of the standard and the DID ecosystem: what issues it answers, how it works, and how Unikname uses it to create human-readable identifiers. If this sounds good to you, let’s get started!

Domain names and trusted third parties

Trusted third parties are everywhere online, especially when it comes to identity. Be them usernames, email addresses, social media handles, users don’t control their digital identities and the identifiers that go with them. But they are not the only ones. 

When you wish to visit a website, you need to know its domain name. The DNS (Domain Name System) protocol resolves this name into an IP address so that your computer can be connected to the correct server. How does this happen? Recursively!

A domain name is made up of several segments, separated by periods. For instance, help.unikname.com. Segments correspond to domains and subdomains with a strict hierarchy. In our example, .com is what is known as a Top Level Domain (TLD). There are many TLD: .org, .info, .io, .network, etc. When resolving a domain name, the name is parsed and each domain or subdomain is solved recursively, starting with the TLD. 

Each domain in the chain is dependent on the domains that come before them. That gives TLD a tremendous amount of power and responsibility. They can censor a website by refusing to resolve the domain name, redirect traffic to another server, or make a whole chunk of the Internet inaccessible if they were to fall.

Everyone and everything on the Internet is subjected to some kind of third party that wields a great deal of power over their digital identity. And that is the problem that the DID standard addresses.

From DID to DID Document

The basic components of DID architecture

Rather than depend on trusted third parties, DID are recorded on verifiable data registries, such as blockchains. By construction, these registries do not depend on a central entity, are censor-proof, and can serve as a permanent record.  

The most important thing about a DID is that, like a domain name, it is resolvable. A DID resolves to a DID document. This document contains a bunch of information about the entity identified by the DID. Such information includes which public keys can be used for authentication, or service endpoints used to interact with the entity. How to go from a DID to its DID Document is method-specific. 

The role of a DID method is to specify how to create, read, update, and delete a DID and the associated DID Document. There are already over 100 published DID methods. Why so many? First of all, by nature of a decentralized system, not everyone has to agree on the best way to go about things, there is no central arbiter. Anyone can create their own method. Some methods only work on a specific blockchain, while others are network-agnostic. Some methods are used to refer to people while others reference objects. Methods can disagree on key formats or use a very specific smart contract to generate an identifier. 

A DID method is just a specification, a blue print for how to interact with a specific kind of DID. Based on these methods, the DIF is building a universal resolver that would be able to resolve a DID from any method into its DID Document. Method creators are invited to add their method to the resolver by implementing the processes described in the DID method specification.

Subjects and controllers, the actors of a DID

DID can be used to refer to absolutely anything, including objects, processes, or even concepts. Some of these entities cannot control themselves. For this reason the DID standard differentiates between a DID subject and its controller.

Let us take the example of a connected light bulb that changes color. The light bulb is installed in a smart home with many other IoT devices, and connected to a gateway. The owner of the house manages all its devices as well as the gateway. Now let us associate a DID to our three entities: DID_L for the light bulb, DID_G for the gateway, and DID_O for the owner. These entities are the subjects of their respective DID. 

The lightbulb is not programmed to control itself. It is either controlled by the gateway or by the homeowner. As such, DID_G and DID_O are both controllers of DID_L. The gateway has the capacity to control itself but can also be controlled by the homeowner. So DID_G and DID_O are also both controllers of DID_G. DID_O is the only controller of DID_O as the homeowner can control its own identity.

To summarize, the DID subject is the entity identified by the DID. In many cases, a DID subject will also be its controller. Example of DID subjects include a person, a group of people, an organization, a connected object, a physical object without connection (i.e. a handbag, an article of clothing), an autonomous software, industrial processes, digital files, crypto-assets (i.e. an NFT), a concept, and many more.

The DID controller is the entity that has the capability to modify the DID document associated with the DID. This will usually mean the entity that has control over some specific cryptographic key pairs. A DID may have several controllers, including itself. When the DID subject is a person, then the DID subject and controller will most likely be one and the same.

Unikname & DID

DID have one small problem: they are non human-readable. In this sense, and keeping with the DNS comparison, DID are more akin to IP addresses than they are domain names. They are machine readable, uniquely and globally identify an entity, but are grossly non-sensical for human beings. In order to use them in our day to day, we need to add a layer of human-readability just as domain names spare us from manipulating IP addresses.

To achieve this, Unikname uses two DID methods, did:uns and did:unik. Both methods use Unikname Network as their verifiable data registry. 

The DID subjects of did:uns are Unikname Network crypto-accounts and, by extension, their owner. We will generally assume that these are human beings that can control their own identity. 

The DID subjects of did:unik are UNIKNAME NFT and, by extension, the UniknameID they represent. As conceptual constructs, UniknameID cannot control themselves. They are owned and controlled by Unikname Network crypto-accounts. Their DID controllers are therefore did:uns. 

Using these two DID methods strongly associates a Unikname Network crypto-account with a UNIKNAME NFT, and by association a person with a UniknameID. To see how this works, let us take the example of a simple digital signature verification. 

Bob signs a document using his crypto-account’s private key. When Viktoria wants to verify its signature, Bob simply gives his UniknameID, @bob. @bob is associated with a did:unik DID. By resolving this DID to its DID Document, Viktoria sees that it is controlled by a did:uns. By resolving this DID, she finds Bob’s crypto-account public key. This public key can be used to verify Bob’s signature.

At the moment, did:unik are only constructed to work with did:uns. But thanks to DID’s built-in interoperability, the method could be extended in the future to work with any other DID. Your UniknameID could then be linked to a Bitcoin, Ethereum, Avalanche, or any other kind of blockchain account. 

In Conclusion

The DID standard, with its use of subject and controller, is capable of identifying pretty much anything. Its use a verifiable data registries as a means of record keeping makes it independent from third parties. DID resolve to DID documents that can contain a host of information about a subject. These documents are maintained solely by the controller of a DID, thus ensuring independence. Unikname is using this standard to ensure interoperability with other projects but also to add a layer of human-readability.

If you would like to learn more about the DID standard, don’t hesitate to take a look at the core specification. Interested in Unikname’s very own decentralized identifier, the UniknameID? Learn more about it on our website. Would you like more technical articles such as this one, tell us about it on our Forum, or tweet at us. And keep watching our blog for more articles about digital identities, decentralization, and blockchain-related concepts.

Need more?

Meet Unikname team to get a demonstration and help integration in your project