The presence of a person in the digital realm is established through their unique identifiers such as their phone number, email address, and social media profiles. Losing any of these identifiers can result in being excluded from social circles and losing valuable professional connections. Although social networks operate in a decentralized manner, in practice, our identities are predominantly associated with centralized providers through our identifiers. This article examines the benefits and drawbacks of this situation, and also explains how decentralized identifiers ( DID ) technology can be used to create an autonomous identification system.
Centralized Identity Providers
Digital subject identifiers serve two main purposes: distinguishing subjects from each other and providing a means of communication. Historically, most digital identifiers rely on centralized authorities, such as governments, banks, and telecom operators. While this approach is easy to implement and understand, it has several limitations.
One major limitation is the inability to change service providers easily. For instance, switching from Gmail to Yandex or Mail.ru is not straightforward, and email forwarding does not solve the problem completely. Similarly, changing mobile operators often means changing phone numbers, resulting in inconvenience and disruption.
Another limitation is the possibility of being blocked by the provider. Social networks, in particular, are known for blocking users for various reasons. Which can cause significant harm to individuals and organizations alike. Additionally, centralized platforms have access to personal data and can manage them without the subject’s knowledge, making them vulnerable to fraud and data breaches.
Moreover, centralized identity providers offer limited functionality, which can be problematic in complex business interactions. While platforms provide convenience and security, excessive monopolization of the market can stifle innovation and limit the variety of possible interactions.
To address these issues and capitalize on the trend towards decentralization, the Decentralized Identifier Working Group was formed under the W3C consortium. Their primary recommendation, Decentralized Identifiers (DIDs) v1.0, proposes an approach to creating and managing entity identities that is independent of centralized organizations. This new approach to digital identification promises to increase security, privacy, and functionality while reducing dependence on centralized authorities.
Decentralized Identifier – DID
Here is an example of a Decentralized Identifier:
did:iota:6x1Xu21MBV6zQpwe9bWkrR9QdnFuYn6d3rtBXg5sBGxn.
At first sight, this string of characters may appear intimidating and difficult to comprehend. Unlike phone numbers or email addresses, which are easily dictated or rewritten, DIDs are plain text strings that include numbers, letters, and other characters. Conforming to the URI standard and consisting of three essential parts.
The first part, “did,” indicates that the URI represents a Decentralized Identifier. The second part, “iota,” denotes the DID method employed, such as the IOTA network in this instance. The last part, “6×1…BGxn,” represents the identifier itself, derived from the public key.
Creating a DID is technically straightforward. On the user’s device, a public and private key pair is generated. And the it is produced from the public key. The private key is then kept by the subject to verify ownership of the Decentralized Identifier by signing messages with the associated private key. With an almost infinite number of potential DID combinations, each locally created DID is globally unique. Removing the need for a centralized registrar to oversee uniqueness.
Nonetheless, DIDs are difficult to read or write manually, which is the cost of their decentralization and security. This leads us to the Zuko Triangle, which asserts that an identifier cannot possess all three characteristics of being human-readable, decentralized, and secure simultaneously. However, QR codes or copying can present the DID. And software typically uses this identifier without the need for users to delve into technical details. For human-readable DIDs, decentralized services like the Ethereum Name Service exist, but a beautiful name comes at a cost. Smart contracts implement such services, requiring payment for their execution. Despite the potential competition for attractive identifiers, dependency on centralized services can be avoided.
How is it determined that it is I who owns this or that DID?
To verify ownership of a DID, a private key is required, which is used to generate the DID. In centralized providers, ownership is typically confirmed through logins, passwords, or physical media like SIM cards or bank cards. The private key can be stored on various mediums. Such as a smartphone, trusted cloud storage, or a physical device like Ledger. Any subject can generate multiple DIDs, similar to a digital signature, without the need for a certification authority.
Who can be the subject of a DID?
The primary purpose of DID is for identifying individuals and organizations. Although it is also possible to assign a DID to pets, IoT devices, or websites. Essentially, anything that can be named in real or virtual life can have a DID. However, it may not be practical for a pet to remember a lengthy seed phrase or wear a hardware wallet on a collar. For this reason, the DID standard separates the subject being identified by the DID from the controller, the person who directly stores the private keys associated with the DID. It is even possible for multiple controllers to be assigned to a single DID.
Public Key Infrastructure
The use cases for DID are diverse, including website authorization, digital signatures for documents, messages, and NFTs. For security reasons, it is not advisable to use the same private key for all operations. DIDDoc allows for the inclusion of multiple keys, each with its own designated role. The storage of keys may vary depending on their importance and frequency of use, such as on a secure mobile device, on paper as a seed phrase, or on a physical crypto wallet like Ledger.
To maintain security, keys should be periodically changed by adding new public keys to DIDDoc and removing the old ones. This can be done without changing the DID itself.
Subject Information
Storing personal data such as email addresses and phone numbers in DIDDoc is not advisable due to potential conflicts with personal data protection laws, which could make it difficult to erase the data permanently. Instead, it is suggested to store links to online resources.
To illustrate this concept, let’s consider an example. An individual can store their resume and contact details on LinkedIn and create a public link to it in DIDDoc. On one hand, the individual can delete their data from LinkedIn at any time. On the other hand, the individual’s contact details will remain independent of the centralized resource, and they can transfer their resume to Yandex Drive or their own server and update the link in DIDDoc. By using DID as their identifier, the individual’s transition from LinkedIn to another site would be seamless and unnoticeable.
Although the JSON-LD format allows for diverse association formats, it is recommended to use specially designed formats such as DIDComm, which is a secure communication protocol that uses DID technology.
Why create multiple IDs?
The issue of personal data leakage is a common one, where sharing a phone number with a store can result in receiving numerous spam calls with no way to prove the source of the leak. Some individuals have resorted to creating multiple email addresses and phone numbers for different groups of contacts, but this can be inconvenient and expensive.
DID, on the other hand, can be generated for free and instantly on the user’s device. Standards such as Peer DID and Aries RFC 0023: DID Exchange Protocol 1.0 recommend using a new DID for each new contact, known as a pairwise relationship, for increased security and privacy. This approach avoids the need to share your contacts with third parties and allows for the easy deletion of compromised DID, as the source of the leak can be identified through the unique identifier.
Public and private DIDs
As mentioned earlier, it is advised to create a unique DID for each new contact, which are private DIDs and are explained in the Peer DID standard. The process of securely exchanging DIDs between two new contacts is explained in Aries RFC 0023.
However, there are situations when we want to share our contact details openly, especially for entrepreneurs who want to make their contacts available to potential customers, or for authors of scientific papers, popular articles, or NFT collections to sign their intellectual property with their public DID to confirm authorship.
The primary difference between public and private DIDs is where the associated DIDDocs are stored. Private DIDDocs are kept only with the second interlocutor, while DIDDocs of public DIDs are stored in a publicly accessible registry or database.
In some cases, such as a WhatsApp group, where each participant’s DID must be known to all others, n-wise relationships come into play. The creation and management of such relationships are outlined in the Aries RFC 0748 protocol.
Registers
As mentioned earlier, every DID is associated with a DIDDoc, and the question arises as to where to store it. There are multiple options available.
In the case of a private DID, no external storage is required for the DIDDoc. Both parties simply store each other’s DIDDoc and exchange them during initial contact. If any party needs to make changes to its DIDDoc, they can simply notify the other party about it.
For a public DID, the DIDDoc must be kept in a public registry so that anyone can access it. Popular public distributed ledgers such as Ethereum, Bitcoin or IOTA are well-suited for this purpose. However, using these networks can involve fees for usage, and if it is implemented as a smart contract, users may have to pay for both reading and writing. Free solutions, such as those based on the IOTA blockchain, also exist.
If DIDs will be used only within a consortium of organizations, corporate blockchains can be used. For example, DIDs can be assigned to employees of these organizations for secure communication, or to IoT devices. Hyperledger Indy offers a specialized ledger for storing and managing DIDs, along with an SDK. Sovrin and Indicio networks are deployed based on Hyperledger Indy and are used by consortiums of organizations. DIDDoc reading in these networks is public, while writing is only possible through consortium members or for a fee.
It is worth noting that centralized repositories can also be used to store DIDs without contradicting the DID concept. An example of this is an implementation based on GitHub.
How to link your DID and a third-party Internet resource
Suppose an organization creates its own decentralized identifier and publishes it on the public network. They then send a signed commercial proposal to their regular customers via email. However, the customers may not be able to verify that the DID belongs to the organization. Although this problem is not trivial and remains unsolved, there is a solution that fits perfectly in this scenario. Organizations have websites with widely-known and highly-readable addresses. Cryptographically linking the DID and the website address can solve this problem. The Well Known DID Configuration standard has been developed for this purpose. It involves specifying the address of the required resource in the DIDDoc and placing a cryptographic proof signed by the DID on the resource itself. This establishes that the DID and the internet resource are controlled by the same entity, which can be verified automatically.
The DID method
The process for generating a DID from a public key, as well as the storage and modification of the DIDDoc are defined by the DID method. These methods are typically named after the distributed registry where the DIDDoc is written, such as did:eth, did:iota, and did:ion. An up-to-date list of current DID methods can be found in the specification.
Currently, there are over a hundred DID methods that have been developed, but this wide variety can create difficulties in implementation. No single software implementation supports at least half of these methods. To address this problem, the Sidetree Protocol was proposed to bring uniformity to existing DID methods.
Conclusion
In conclusion, the concept of decentralized identifiers (DIDs) has opened up new opportunities for secure and privacy-respecting digital communication. DIDs provide a way for individuals and organizations to have full control over their digital identities. And to easily and securely authenticate themselves in online interactions. The use of DIDs is being explored in various fields, including finance, healthcare, and e-commerce. With potential applications in identity verification, credential management, and secure data sharing. However, the technology is still evolving, and there are challenges to be addressed, such as standardization, interoperability, and adoption. Nonetheless, with continued research and development, decentralized identifiers have the potential to transform the way we communicate and interact online, creating a more secure, trustworthy, and decentralized internet for everyone.