INTRODUCTION

Many of us, both as individuals and as businesses, utilize globally unique IDs in several situations. They're used as phone numbers, email addresses, social media usernames, ID numbers (for passports, driver's licenses, tax IDs, and health insurance), and product identifiers (serial numbers, barcodes, RFIDs). URIs (Uniform Resource Identifiers) are utilized for resources on the Internet, and each web page you see in a browser has a globally unique URL (Uniform Resource Locator).

We have no control over the vast majority of these globally unique IDs. External authorities issue them and decide who or what they refer to and when they can be canceled. They're only helpful in specific situations and are only acknowledged by certain bodies that aren't our choice. With the demise of an organization, they may vanish or cease to be valid. They could divulge personal information needlessly. In many circumstances, they may be fraudulently copied and asserted by a malevolent third party, referred to as "identity theft."

Decentralized Identifiers (DIDs) are a new type of unique identifier. They are intended to allow people and organizations to create their own IDs with the help of trusted systems. Entities can verify ownership over these new IDs by authenticating them using cryptographic proofs like digital signatures.

DIDs

DIDs (decentralized identifiers) are a new form of identifier that allows for decentralized, verified digital identification. A DID is any topic specified by the DID's controller (e.g., a person, organization, item, data model, abstract entity, etc.). DIDs, unlike traditional federated identifiers, are meant to be independent of centralized registries, identity providers, and certificate authorities. While other parties may be employed to assist in finding information relating to a DID, the design allows the DID's controller to prove authority over it without needing authorization from anyone else. DIDs are Uniform Resource Identifiers (URIs) that link a DID subject to a DID document, allowing for trusted interactions with that subject.

Each DID document can include cryptographic content, verification techniques, or services that enable a DID controller to demonstrate control of the DID. Trusted interactions with the DID subject are enabled through services. If the DID subject is an information resource like a data model, a DID may provide a way to return the DID subject itself.

A DID is a three-part text string that includes:

1) the did URI scheme identification

2) the DID method identifier

3) the DID method-specific identifier.

The DID in the preceding example resolves to a DID document. A DID document provides information associated with the DID, such as methods for cryptographically authenticating a DID controller.

A simple DID document
A simple DID document

Architecture Overview

Basic overview of the main components of the Decentralized Identifier architecture.

Basic overview of the main components of the Decentralized Identifier architecture
Basic overview of the main components of the Decentralized Identifier architecture. Source: w3c.github.io/

DIDs and DID URL: Decentralized Identifier or DID is a three-part URI. DID documents can be resolved from DIDs. To locate a specific resource, a DID URL expands the syntax of a simple DID to include other conventional URI components such as path, query, and fragment.

DID subjects: the entity that the DID identifies. DID Subject can be anything: person, group, organization, thing, or concept.

DID controllers: A DID controller is a person or entity with authority to modify a DID document. The DID method specifies the procedure for approving a DID controller.

Verifiable data registries: The system supports writing DID and returning data to create DID documents. Example: distributed ledgers, decentralized file systems, peer-to-peer networks, …

DID documents: DID documents contain associated information with a DID. They describe verification techniques, such as cryptographic public keys and services relevant to interactions with the DID subject.

DID methods: DID methods are the mechanisms for creating, resolving, updating, and deactivating a certain type of DID and its accompanying DID document. Separate DID method specifications are used to define DID methods.

DID resolvers: A DID resolver is a system component that takes a DID as input and outputs a DID document that conforms to the DID.

DID URL dereferencers and DID URL dereferencing: A DID URL dereferencer is a system component that takes a DID URL as an input and produces a resource as output.

References


[1] Decentralized Identifiers (DIDs) v1.o, github.com, accessed June 22th, 2022.