An Overview of Decentralized Identifiers “DIDs”
Recent content publications have been focused on expanding our readers’ knowledge of public key cryptography, proof-of-work mining’s real environmental impacts, and fundamental aspects of the greater crypto asset space. This piece will deviate from covering a cryptocurrency-specific topic and instead focus on providing an overview of a critical component of the decentralized future: decentralized identifiers, also known as DIDs.
First and foremost, a DID is a globally unique and persistent digital identifier that allows for the creation of private, secure, peer-to-peer connections between two parties. Any individual, or entity, can spin up as many different DIDs as they so choose — in fact, it is perfectly reasonable for an individual to create as many DIDs as personal relationships they have.
A unique, secure identifier for each channel of communication.
Decentralized Identifiers are intended to be a stepping stone away from centralized, gate-keeping third parties who currently dominate the internet, and who reap the benefits of access to consumer data. However, while DIDs are not yet completely standardized and ubiquitous across protocols, the World Wide Web Consortium (W3C) released a recommended specification this past July which will serve as the basis for this exploration.
This piece will cover:
- Brief, historical context for digital identifiers.
- Why do we need DIDs, and what problems do they solve?
- Generalized DID infrastructural components; how do they work?
- How can DIDs impact baseline privacy online?
Setting the Scene
The need for globally persistent digital identifiers not tied to one’s personal data is not a new phenomenon. The cypherpunk movement of the late 1980s represents a clear understanding of the ramifications of the global interconnectedness that would result from the internet’s proliferation: long before smartphones, forward-thinking software developers saw a need for privacy-preserving solutions. These individuals — correctly — hypothesized that as the internet grew in popularity (and complexity) that more and more unsuspecting users would have their physical identities compromised as a result of naivety, or protocol misuse.
One of the earliest attempts at a decentralized digital identification protocol was the Universally Unique Identifiers (UUIDs), otherwise known as Globally Unique Identifiers (GUIDs). This protocol was developed throughout the 1980s and was first standardized by the Open Software Foundation, and subsequently by the IETF RFC 4122 in 2005.
Ultimately, these protocols lacked a critically important feature: they were unable to be resolved in a permissionless, decentralized manner. Said another way, if there was an issue with a digital ID you possessed (according to these earlier standards), the only way that issue would be resolved is via a centralized registration authority. Earlier standards were also unable to implement the ability to cryptographically verify the ownership of a particular document, credential, or proof.
In order to achieve a digital, self-sovereign identity, a new class of identifiers is needed that fulfills the following requirements: persistence, global resolvability, cryptographic verifiability, and decentralization.
Why DIDs?
The need for decentralized digital identifiers is illustrated by the current state of affairs playing out in the internet landscape — sometimes referred to as Web2.0. Within this landscape, centralized intermediaries are fundamentally in control of users’ identifiers — across several platforms, in some cases. Facebook, Google, email service providers, and mobile service providers are all examples of such intermediaries; often, users’ metadata associated with login identifiers is explicitly leveraged across multiple platforms to increase the efficacy of advertising campaigns.
Whether explicit or implicit, this leveraging of sensitive client information is the main reason why these Web2.0 social media platforms are “free” to use. Even a protocol like WhatsApp, an end-to-end encrypted messaging service, is still at risk of enterprise-level coercion; most users are completely unaware that this encryption can be broken. More and more, though, users are realizing that their online identities should not be permissioned by multinational tech corporations.
As expressed in the introduction, DIDs are typically associated with cryptographic material, such as public keys, and service endpoints, for establishing secure communication channels. An individual user (or entity) is able to create as many of these identifiers as they please, which is a practical strategy if one’s intention is to disrupt heuristics-based surveillance algorithms. Other impactful use cases come from existing applications that might benefit from self-administered, cryptographically verifiable identifiers: driver’s licenses, state or national IDs, and organizational IDs, just to name a few.
Much of the conversation regarding the practical use of DIDs is centered around what is known as verifiable credentials. Verifiable Credentials, or VCs, are essentially “digital watermarks” for claims data achieved via a combination of public key cryptography and privacy-preserving techniques to prevent correlation. In the most simplistic sense, a VC is composed of three parts: a subject (individual or entity), an issuer (organization of some sort), and a claim. The claim can be any statement that can be made and is also able to be proven true or false. One could imagine a VC being used to verify a customer’s age when attempting to purchase alcohol: instead of handing over a driver’s license, which contains sensitive information not relevant to the purchase, the store would be able to verify that a customer was of legal age through the VC attached to the particular DID and would need no further information.
Before moving on to outline the basic proposed infrastructure of DID protocols, it is worth noting two things: first, DIDs are not yet widely implemented and used, therefore the information discussed in this piece should be supplemented with disclosures, statements, and specifications from the W3C’s official repository. Second, please note that verifiable credentials are technically not a part of the DID specification, and are in fact meant to be another layer on top of DIDs.
DID Infrastructure
Decentralized digital identifiers utilize the same basic technologies that cryptocurrencies do: distributed ledgers, otherwise known as blockchains. Blockchains can be thought of as a sort of digital storage locker, where once a value is included on-chain, it is from then on immutable and unalterable (barring a sophisticated reorganization attack). DID infrastructure can be imagined as a global key-value database in which the keys are DIDs and the values are DID documents.
The purpose of these documents is to describe the public keys, authentication protocols, and service endpoints necessary to bootstrap cryptographically-verifiable interactions with the identified entity. Per the W3C’s current specification, DID documents contain six components (some of which are optional). First is the DID itself, which renders the DID document a fully self-describing entity. The second is the set of cryptographic materials (e.g. public keys) that can be used for authentication or interaction with the DID subject. The third is a set of cryptographic protocols for interacting with the DID subject, such as authentication and capability delegation.
A set of service endpoints, which basically describe where and how to interact with the DID subject. Timestamps for auditing purposes, and finally, optional JSON-LD signatures which are meant to verify the integrity of the DID document.
DIDs and DID documents can be adapted to any modern blockchain, distributed ledger, or another decentralized network capable of resolving a unique key to a unique value. Versatility and flexibility are positive aspects of the DID specification, but users must be aware of the trade-offs associated with storing any data on a blockchain. Blockchains are immutable, unalterable ledgers that are transparent and public in nature (in the majority of cases). That very nature is a potential security threat to users who are not following privacy best practices: any mistakes made (and stored) on the blockchain, live there forever.
Privacy-Enhancing Solutions
DIDs can be associated with publicly known entities or individuals, or pseudonymously (privately, for all intents and purposes). The former case would be useful for institutions or organizations who have already established a strong public reputation, and especially useful for those organizations who might wish to issue verifiable credentials. Conversely pseudonymous DIDs might be better suited for privacy-conscious individuals who wish to establish secure, peer-to-peer communication channels.
The above distinction hopefully highlights the versatility of use-cases that DIDs are suitable for; DID infrastructure is such that it can enable privacy-by-design at the lowest levels. So long as the particular implementation follows privacy best practices, such as the following. Pairwise-pseudonymous DIDs is a term that describes the practice of using a unique identifier for every peer-to-peer communication channel that a user establishes. This practice significantly disrupts the ability of surveillance algorithms to track a user’s activity, and the management of multiple DIDs is about as complicated as managing an address book.
Another incredibly important aspect of privacy with respect to distributed ledgers is that generally speaking, no personal/sensitive data should be stored on the said ledger. Barring the relatively unlikely event of a reorganization attack on the chain, any information stored on a blockchain should be assumed to be immutable. Moreover, any encrypted or hashed data is technically a global correlation point when the data is shared with multiple parties — which is the case for any decentralized system. In a hypothetical future scenario where the encryption is broken (e.g. quantum computing), the previously encrypted data would then live forever on the immutable ledger.
Best practice for personal/sensitive data is to not store it on a blockchain, distributed ledger, or another decentralized network. However, because DIDs utilize decentralized public key infrastructure, users are able to selectively disclose their data in a few ways.
The first is to utilize secure, encrypted, private peer-to-peer connections — which could be as complicated as an encryption algorithm that only the communicating parties are able to decrypt. Or something as straightforward as meeting face-to-face in a provably secure location.
DIDs are also able to utilize zero-knowledge proof cryptography for data disclosure minimization. This is because, by using a zero-knowledge proof, one party (the prover) can prove to another party (the verifier) that a given statement is true while the prover avoids conveying any additional information apart from the fact that the statement is indeed true. Think again about the example of a user attempting to purchase wine from the store, if that user’s DID implements zero-knowledge proof cryptography, the store would be able to verify that the user is of legal age without any knowledge of their exact age.
Conclusions
The decentralization of digital identifiers is by no means a new idea — the first attempts made during the genesis of the cypherpunk movement in the 1980s set the foundation for more recent attempts. All of which are aimed at increasing users’ data sovereignty as they interact with the global internet. Centralized intermediaries are not required for the internet of tomorrow, and DIDs are a step in the right direction.
Attempts at standardization of DID specifications are ongoing by the likes of the W3C and others. As new iterations of, and use cases for DIDs emerge, it will be vitally important to have as many savvy users as possible, in order to provide timely and actionable feedback for said implementations.
The purpose of this piece was to briefly outline some of the major components in the decentralized identifier landscape currently, as well as their use cases and trade-offs. There is a saying in the privacy-technology space along the lines of: “learn to use the tools before you need to use the tools.” DIDs are a salient example of such a tool.
If this topic interests you, check out the full specification from the W3C and dig into the material already laid out.
We sincerely hope that this content has been valuable to you and has helped broaden your knowledge on this topic. Thank you for reading!
🚀Better Indexes, Better Returns — VegaX
Questions? 👉🏼 info@vegaxholdings.com
🎯Follow, Message, Tweet, Clap, & Join Us Here:
As we continue to expand our digital footprint, here is where you can find us:
VegaX Site | VegaX Twitter | VegaX FB | VegaX LinkedIn | VegaX IG
VegaX Holdings creates next-generation indices and financial products that are needed to support the growth of the cryptocurrency industry and improve returns for investors worldwide. Learn how to get better returns today: www.VegaXHoldings.com
