Self-Sovereign Identity Is Here—And It Starts with DIDs

This article examines the technology of Decentralized Identifiers (DID)—a new W3C standard that returns control over digital identity to users. It will analyze the essence of DIDs, their structure, the problems they solve, and the reasons why they are a fundamental element for building trusted and private interactions on the next-generation internet (Web3). The article also briefly mentions that DIDs lay the groundwork for technologies like Verifiable Credentials and Zero-Knowledge Proofs, which will be explored in subsequent publications. The Problem of Digital Identity Digital identity has become an integral part of modern life, yet the prevailing models for its implementation carry significant limitations and risks. Understanding these shortcomings is critical to appreciating the value and necessity of new approaches, such as decentralized identifiers. The Current Approach: Centralized (Social Logins) and Federated (SSO) Identity Models In the modern digital space, users primarily identify themselves in two ways. The first is the centralized model, where a separate account is created for each website or service. An alternative is to use accounts from major technology providers, such as Google or Facebook, to log into third-party resources. This approach, while convenient, transfers significant control and data to these central providers.¹ centralized model The second common method is the federated identity model, often implemented through Single Sign-On (SSO) systems. In this model, a single organization, such as an employer or an educational institution, vouches for the user's identity, granting them access to a range of affiliated services. This simplifies access management in corporate or educational environments but still relies on trust in a central identity provider within the federation.² federated identity model Both of these models, despite their prevalence and certain conveniences, suffer from fundamental flaws that have spurred the search for new solutions. Key Drawbacks: Lack of User Control, Data Silos, Risks of Mass Breaches, and Provider Dependency Existing digital identity models have several serious drawbacks that affect both individual users and organizations: Lack of User Control: In centralized and federated systems, users do not actually own their identity data. This data is stored and managed by third-party providers who can change terms of service, block access, or use the data for their own commercial interests without the user's explicit and informed consent for each action.³ Users often have no complete picture of how their data is used or shared with third parties.² Data Fragmentation (Data Silos): A user's identity data is scattered across numerous isolated databases of various services. This creates "data silos," complicating the management of one's own identity and the formation of a holistic view of it.¹ Each application or service stores its own fragment of information, and the user is forced to manage dozens of accounts. Risks of Mass Data Breaches: The concentration of large volumes of personal data in centralized repositories makes them an attractive target for cyberattacks. A successful attack on one major provider can lead to the compromise of millions of users' data, resulting in identity theft, financial loss, and other negative consequences.³ Often, data is stored without proper encryption or is shared with third parties without user consent, exacerbating the risks.⁶ Provider Dependency: Users and services that rely on centralized or federated identity providers become heavily dependent on their stability, policies, and even their existence. If a provider ceases operations, changes its terms of service, or experiences technical failures, users can lose access to their accounts and associated services.⁷ This creates a single point of failure for a significant part of a user's digital life. Lack of User Control: In centralized and federated systems, users do not actually own their identity data. This data is stored and managed by third-party providers who can change terms of service, block access, or use the data for their own commercial interests without the user's explicit and informed consent for each action.³ Users often have no complete picture of how their data is used or shared with third parties.² Lack of User Control: Data Fragmentation (Data Silos): A user's identity data is scattered across numerous isolated databases of various services. This creates "data silos," complicating the management of one's own identity and the formation of a holistic view of it.¹ Each application or service stores its own fragment of information, and the user is forced to manage dozens of accounts. Data Fragmentation (Data Silos): Risks of Mass Data Breaches: The concentration of large volumes of personal data in centralized repositories makes them an attractive target for cyberattacks. A successful attack on one major provider can lead to the compromise of millions of users' data, resulting in identity theft, financial loss, and other negative consequences.³ Often, data is stored without proper encryption or is shared with third parties without user consent, exacerbating the risks.⁶ Risks of Mass Data Breaches: Provider Dependency: Users and services that rely on centralized or federated identity providers become heavily dependent on their stability, policies, and even their existence. If a provider ceases operations, changes its terms of service, or experiences technical failures, users can lose access to their accounts and associated services.⁷ This creates a single point of failure for a significant part of a user's digital life. Provider Dependency: These shortcomings are not isolated technical inconveniences; they are interconnected symptoms of a fundamental misalignment between the architecture of the traditional internet and users' needs for sovereignty, security, and privacy. The centralization of data with providers leads to its concentration, which increases the risk of breaches. Dependence on multiple providers creates fragmentation. The user's lack of control over their data held by these providers makes them vulnerable. Collectively, these factors create an environment where the user is not the true owner of their digital identity, which has served as a powerful impetus for seeking alternative solutions. Table 1: Comparison of Digital Identity Models Table 1: Comparison of Digital Identity Models Characteristic Centralized Model (e.g., Social Login) Federated Model (e.g., SSO) Self-Sovereign Identity (SSI) Data Control With the identity provider With the identity provider within the federation With the user Identity Data Storage Centralized with the provider Centralized with the provider within the federation Decentralized, under user control (e.g., in a wallet) Risk of Mass Breach High (single point of failure) Medium (depends on the security of the federation provider) Low (data is not stored centrally) Data Fragmentation High (data with each service or provider) Medium (data with the federation provider) Low (user controls their data) Provider Dependency High High (on the federation provider) Minimal (on specific DID methods, but not a single provider) Privacy Low (provider sees activity) Medium (federation provider may see activity) High (user controls data disclosure) Characteristic Centralized Model (e.g., Social Login) Federated Model (e.g., SSO) Self-Sovereign Identity (SSI) Data Control With the identity provider With the identity provider within the federation With the user Identity Data Storage Centralized with the provider Centralized with the provider within the federation Decentralized, under user control (e.g., in a wallet) Risk of Mass Breach High (single point of failure) Medium (depends on the security of the federation provider) Low (data is not stored centrally) Data Fragmentation High (data with each service or provider) Medium (data with the federation provider) Low (user controls their data) Provider Dependency High High (on the federation provider) Minimal (on specific DID methods, but not a single provider) Privacy Low (provider sees activity) Medium (federation provider may see activity) High (user controls data disclosure) Characteristic Centralized Model (e.g., Social Login) Federated Model (e.g., SSO) Self-Sovereign Identity (SSI) Characteristic Characteristic Characteristic Centralized Model (e.g., Social Login) Centralized Model (e.g., Social Login) Centralized Model (e.g., Social Login) Federated Model (e.g., SSO) Federated Model (e.g., SSO) Federated Model (e.g., SSO) Self-Sovereign Identity (SSI) Self-Sovereign Identity (SSI) Self-Sovereign Identity (SSI) Data Control With the identity provider With the identity provider within the federation With the user Data Control Data Control Data Control With the identity provider With the identity provider With the identity provider within the federation With the identity provider within the federation With the user With the user Identity Data Storage Centralized with the provider Centralized with the provider within the federation Decentralized, under user control (e.g., in a wallet) Identity Data Storage Identity Data Storage Identity Data Storage Centralized with the provider Centralized with the provider Centralized with the provider within the federation Centralized with the provider within the federation Decentralized, under user control (e.g., in a wallet) Decentralized, under user control (e.g., in a wallet) Risk of Mass Breach High (single point of failure) Medium (depends on the security of the federation provider) Low (data is not stored centrally) Risk of Mass Breach Risk of Mass Breach Risk of Mass Breach High (single point of failure) High (single point of failure) Medium (depends on the security of the federation provider) Medium (depends on the security of the federation provider) Low (data is not stored centrally) Low (data is not stored centrally) Data Fragmentation High (data with each service or provider) Medium (data with the federation provider) Low (user controls their data) Data Fragmentation Data Fragmentation Data Fragmentation High (data with each service or provider) High (data with each service or provider) Medium (data with the federation provider) Medium (data with the federation provider) Low (user controls their data) Low (user controls their data) Provider Dependency High High (on the federation provider) Minimal (on specific DID methods, but not a single provider) Provider Dependency Provider Dependency Provider Dependency High High High (on the federation provider) High (on the federation provider) Minimal (on specific DID methods, but not a single provider) Minimal (on specific DID methods, but not a single provider) Privacy Low (provider sees activity) Medium (federation provider may see activity) High (user controls data disclosure) Privacy Privacy Privacy Low (provider sees activity) Low (provider sees activity) Medium (federation provider may see activity) Medium (federation provider may see activity) High (user controls data disclosure) High (user controls data disclosure) The Emergence of Self-Sovereign Identity (SSI): The Concept of Sovereign Identity as a Response to Existing Problems In response to the problems described above, the concept of Self-Sovereign Identity (SSI) emerged. SSI is a paradigm in which individuals and organizations gain full and exclusive control over their digital identity data.¹ Instead of relying on external providers to store and manage their identities, users themselves become the sovereigns of their data, deciding what information to provide, to whom, and under what conditions.⁹ Self-Sovereign Identity (SSI) The key principles of SSI include²: Existence/Autonomy: Users exist independently of any registry or organization. Control: Users control their identifiers and data. Access: Users always have access to their data. Transparency: Systems and algorithms must be transparent. Persistence: Identifiers should be long-lasting. Portability: Identity data and services must be portable. Interoperability: Identifiers must work across system and jurisdiction boundaries. Consent: The use of a user's data requires their consent. Minimization of Data Disclosure: Only the minimum necessary information for a specific interaction is disclosed. Protection: The rights of users must be protected. Existence/Autonomy: Users exist independently of any registry or organization. Existence/Autonomy: Control: Users control their identifiers and data. Control: Access: Users always have access to their data. Access: Transparency: Systems and algorithms must be transparent. Transparency: Persistence: Identifiers should be long-lasting. Persistence: Portability: Identity data and services must be portable. Portability: Interoperability: Identifiers must work across system and jurisdiction boundaries. Interoperability: Consent: The use of a user's data requires their consent. Consent: Minimization of Data Disclosure: Only the minimum necessary information for a specific interaction is disclosed. Minimization of Data Disclosure: Protection: The rights of users must be protected. Protection: SSI is not just a set of technologies, but a fundamental shift in the philosophy of identity management, aimed at restoring the balance of power in favor of the user. Thesis: DIDs are the technical foundation for implementing the SSI concept, offering a standard way to create and manage decentralized identity The concept of SSI requires a technical foundation for its practical implementation. This foundation is Decentralized Identifiers (DIDs). DIDs are a new type of identifier, standardized by the World Wide Web Consortium (W3C), that allows for the creation and management of digital identity in a decentralized manner.³ Decentralized Identifiers (DIDs) DIDs give users the ability to generate their own globally unique identifiers without resorting to centralized registrars or identity providers.¹¹ Control over a DID and its associated information remains exclusively with the user. It is DIDs that provide the technical means to bring the principles of SSI to life, offering a standardized approach to creating, resolving, updating, and revoking identifiers that are sovereign by nature. The emergence of SSI and the development of DIDs reflect a broader trend of decentralization and a move towards an "ownership economy" in the digital space, which is one of the key characteristics of Web3.¹² This is not only a technological shift but also a socio-economic one, where users seek to regain control over their data and digital assets, reducing their dependence on large technology corporations. The successful implementation of DIDs and SSI has the potential to radically change the business models of many internet services that are currently based on the collection and monetization of user data, stimulating the emergence of new models based on trust and consent. What is a Decentralized Identifier (DID)? Decentralized Identifiers (DIDs) represent a new approach to identification in the digital world, designed to overcome the limitations of traditional systems. They are a key element for building self-sovereign identity systems. Definition: A DID is a new type of globally unique identifier that does not depend on centralized registries and is created by the user themselves According to the W3C definition, a Decentralized Identifier (DID) is a new type of globally unique identifier that enables verifiable, decentralized digital identity.⁷ The key feature of DIDs is that they are designed to be independent of centralized registries, identity providers, and certificate authorities.⁸ This means that any subject (a person, organization, device, data model, etc.) can create their own DID without needing permission from any central authority.⁴ Control over the DID and its associated DID Document belongs entirely to its creator (the DID controller).¹⁴ Decentralized Identifier (DID) This independence from central authorities and user-side control are the fundamental differences between DIDs and traditional identifiers like email addresses, social media usernames, or passport numbers, which are issued and managed by external organizations. DID Syntax: A Breakdown of the did:method:specific-identifier Structure did:method:specific-identifier Every DID is a simple text string that conforms to the standardized Uniform Resource Identifier (URI) syntax. The generic DID syntax is defined by the W3C and consists of three parts⁷: did:method:specific-identifier did:method:specific-identifier Let's break down each component: did: This is the URI scheme prefix that uniquely identifies the string as a decentralized identifier. It is a constant for all DIDs.¹³ method (DID Method): This part defines the specific DID method that governs this DID. A DID method is a specification that describes how DIDs of this type are created, resolved (i.e., how associated information is found), updated, and deactivated.¹⁰ The method name points to the underlying system or technology used to manage the DID (e.g., a specific blockchain, a web server, or a cryptographic algorithm). Examples of method names include ethr, web, key, ion, sov, btcr. specific-identifier (Method-Specific Identifier): This is a unique string of characters that identifies a specific subject within the scope of the given DID method. The format and generation process for this part are defined by the specification of the corresponding DID method.⁷ did: This is the URI scheme prefix that uniquely identifies the string as a decentralized identifier. It is a constant for all DIDs.¹³ did method (DID Method): This part defines the specific DID method that governs this DID. A DID method is a specification that describes how DIDs of this type are created, resolved (i.e., how associated information is found), updated, and deactivated.¹⁰ The method name points to the underlying system or technology used to manage the DID (e.g., a specific blockchain, a web server, or a cryptographic algorithm). Examples of method names include ethr, web, key, ion, sov, btcr. method ethr web key ion sov btcr specific-identifier (Method-Specific Identifier): This is a unique string of characters that identifies a specific subject within the scope of the given DID method. The format and generation process for this part are defined by the specification of the corresponding DID method.⁷ specific-identifier Examples of DIDs: Examples of DIDs: did:ethr:0xE6Fe788d8ca2144080b0f6aC7F48480b2AEfa9a6 – A DID using the ethr method (based on Ethereum), where the specific identifier is an Ethereum address.¹³ did:web:example.com – A DID using the web method, where the specific identifier is a domain name. The DID Document for such a DID is typically hosted on a web server at the address https://example.com/.well-known/did.json.¹⁷ did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH – A DID using the key method, where the specific identifier is directly derived from a public cryptographic key.¹⁸ did:ion:EiClkZMDxPKqC9c-umQfTkR8vvZ9JPhl_xLDI9Nfk38w5w – A DID using the ion method, which operates on top of the Bitcoin blockchain.¹⁹ did:ethr:0xE6Fe788d8ca2144080b0f6aC7F48480b2AEfa9a6 – A DID using the ethr method (based on Ethereum), where the specific identifier is an Ethereum address.¹³ did:ethr:0xE6Fe788d8ca2144080b0f6aC7F48480b2AEfa9a6 ethr did:web:example.com – A DID using the web method, where the specific identifier is a domain name. The DID Document for such a DID is typically hosted on a web server at the address https://example.com/.well-known/did.json.¹⁷ did:web:example.com web https://example.com/.well-known/did.json did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH – A DID using the key method, where the specific identifier is directly derived from a public cryptographic key.¹⁸ did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH key did:ion:EiClkZMDxPKqC9c-umQfTkR8vvZ9JPhl_xLDI9Nfk38w5w – A DID using the ion method, which operates on top of the Bitcoin blockchain.¹⁹ did:ion:EiClkZMDxPKqC9c-umQfTkR8vvZ9JPhl_xLDI9Nfk38w5w ion Understanding this syntax is critically important as it ensures the universal recognizability of DIDs and indicates how a given identifier should be interpreted and processed. The standardization of the DID syntax is a key factor for ensuring future interoperability. Without a unified syntax, different systems would be unable to "understand" and resolve each other's DIDs, which would lead to the creation of new "identity islands," similar to the current isolated data silos. A unified syntax allows for the development of universal tools, such as resolvers and wallets, capable of working with any DID by knowing its method, which lays the foundation for a network effect and widespread adoption of the technology. Key Principles: Control, Verifiability, Privacy, and Portability Decentralized Identifiers are designed with a number of fundamental principles in mind, which reflect the goals of self-sovereign identity and distinguish them from traditional identifiers¹⁴: Control: The DID subject (or their authorized controller) has full and exclusive control over their DID and its associated DID Document. This includes the ability to create, update, and deactivate the DID without needing permission from any third party.¹⁵ This principle returns power over their digital identity to the users. Verifiability: The authenticity of a DID and the fact of control over it can be cryptographically verified. This is typically achieved through digital signatures, where the private key corresponding to a public key listed in the DID Document is used to prove control.¹³ Any party can verify such a signature using publicly available information from the DID Document. Privacy: DIDs are designed to enhance user privacy. They allow interaction with various services while minimizing the disclosure of personal information. Users themselves decide what data to provide and to whom.¹¹ Moreover, a single subject can have multiple DIDs for different contexts or interactions, which makes it difficult to correlate their actions and create a unified profile without their consent.⁴ Portability: DIDs are not tied to any specific provider, application, or system. The identity represented by a DID can be used across various platforms and services that support the relevant standards.² This provides freedom from "vendor lock-in" and allows users to easily port their identity. Control: The DID subject (or their authorized controller) has full and exclusive control over their DID and its associated DID Document. This includes the ability to create, update, and deactivate the DID without needing permission from any third party.¹⁵ This principle returns power over their digital identity to the users. Control: Verifiability: The authenticity of a DID and the fact of control over it can be cryptographically verified. This is typically achieved through digital signatures, where the private key corresponding to a public key listed in the DID Document is used to prove control.¹³ Any party can verify such a signature using publicly available information from the DID Document. Verifiability: Privacy: DIDs are designed to enhance user privacy. They allow interaction with various services while minimizing the disclosure of personal information. Users themselves decide what data to provide and to whom.¹¹ Moreover, a single subject can have multiple DIDs for different contexts or interactions, which makes it difficult to correlate their actions and create a unified profile without their consent.⁴ Privacy: Portability: DIDs are not tied to any specific provider, application, or system. The identity represented by a DID can be used across various platforms and services that support the relevant standards.² This provides freedom from "vendor lock-in" and allows users to easily port their identity. Portability: These principles collectively form the basis for a fairer, more secure, and user-centric digital ecosystem. The global uniqueness of DIDs, combined with user-side control, directly addresses the problems of identity fragmentation and provider dependency. The user becomes the single point of integration for their identity, able to interact with various services without creating a new, isolated account each time. While these principles sound appealing, their technical implementation, especially key management and understanding the diversity of DID methods, can be complex for the average user. This implies the need for user-friendly interfaces (wallets, agents) that will abstract away this complexity, making DIDs accessible to the mass user, much like how browsers hide the complexity of HTTP and DNS protocols. Key Components of the DID Ecosystem The decentralized identifier ecosystem consists of several interconnected components that work together to ensure its functionality and enable the principles of self-sovereign identity to be realized. DID Document Purpose: Purpose: The DID Document is a structured document, usually in JSON or JSON-LD format, that contains information related to a specific DID.⁷ Its primary purpose is to provide the metadata and mechanisms necessary to use the DID in trusted and verifiable digital interactions.⁸ The DID Document describes the subject identified by the DID and the ways to interact with it.¹⁴ Content: Content: According to the W3C DID Core specification, a DID Document includes the following key elements¹⁴: id (Identifier): A mandatory field containing the DID to which this document pertains. @context (JSON-LD Context): Used to interpret the document as JSON-LD, ensuring semantic compatibility. It usually references the standard W3C DID context. verificationMethod: A set of entries describing cryptographic public keys associated with the DID. Each verification method has its own id (a DID URL), type (key type, e.g., Ed25519VerificationKey2020 or JsonWebKey2020), controller (the DID of the key's controller), and the public key material itself (e.g., in publicKeyJwk or publicKeyMultibase format). These keys are used for authentication, digital signatures, encryption, and other cryptographic operations. Verification Relationships: These properties (authentication, assertionMethod, keyAgreement, capabilityInvocation, capabilityDelegation) specify which verificationMethods can be used for specific purposes. For example, keys listed in authentication are intended for authenticating the DID subject, while keys in assertionMethod are for creating digital signatures on behalf of the subject (e.g., when issuing Verifiable Credentials). service (Service Endpoints): A set of entries describing ways to interact with the DID subject. Each service endpoint has an id, type (service type, e.g., LinkedDomains or DIDCommMessaging), and serviceEndpoint (a URL or other service identifier to which requests can be made). These can be addresses for exchanging encrypted messages, Verifiable Credential repositories, etc. controller: The DID (or a list of DIDs) of the entity authorized to make changes to this DID Document. alsoKnownAs: A set of URIs pointing to other identifiers that refer to the same DID subject. id (Identifier): A mandatory field containing the DID to which this document pertains. id @context (JSON-LD Context): Used to interpret the document as JSON-LD, ensuring semantic compatibility. It usually references the standard W3C DID context. @context verificationMethod: A set of entries describing cryptographic public keys associated with the DID. Each verification method has its own id (a DID URL), type (key type, e.g., Ed25519VerificationKey2020 or JsonWebKey2020), controller (the DID of the key's controller), and the public key material itself (e.g., in publicKeyJwk or publicKeyMultibase format). These keys are used for authentication, digital signatures, encryption, and other cryptographic operations. verificationMethod id type Ed25519VerificationKey2020 JsonWebKey2020 controller publicKeyJwk publicKeyMultibase Verification Relationships: These properties (authentication, assertionMethod, keyAgreement, capabilityInvocation, capabilityDelegation) specify which verificationMethods can be used for specific purposes. For example, keys listed in authentication are intended for authenticating the DID subject, while keys in assertionMethod are for creating digital signatures on behalf of the subject (e.g., when issuing Verifiable Credentials). Verification Relationships: authentication assertionMethod keyAgreement capabilityInvocation capabilityDelegation verificationMethod authentication assertionMethod service (Service Endpoints): A set of entries describing ways to interact with the DID subject. Each service endpoint has an id, type (service type, e.g., LinkedDomains or DIDCommMessaging), and serviceEndpoint (a URL or other service identifier to which requests can be made). These can be addresses for exchanging encrypted messages, Verifiable Credential repositories, etc. service id type LinkedDomains DIDCommMessaging serviceEndpoint controller: The DID (or a list of DIDs) of the entity authorized to make changes to this DID Document. controller alsoKnownAs: A set of URIs pointing to other identifiers that refer to the same DID subject. alsoKnownAs The DID Document is the "public passport" of a DID, providing all the necessary information to establish trusted interactions with its subject and verify its claims. Its standardized structure is critically important for ensuring interoperability between different systems and applications that use DIDs. DID Methods Definition: Definition: A DID method is a specification that defines how a specific type of DID (identified by the method prefix in the DID string, e.g., ethr in did:ethr:...) and its associated DID Document are created, read/resolved, updated, and deactivated—the so-called CRUD operations.⁸ Each DID method is tied to a specific underlying system, called a "Verifiable Data Registry," which can be a blockchain, another distributed ledger technology (DLT), a decentralized file system, or even traditional web infrastructure.¹⁶ ethr did:ethr:... Examples of DID Methods and a Brief Overview of Their Differences: Examples of DID Methods and a Brief Overview of Their Differences: There are numerous DID methods, each optimized for specific use cases and with its own trade-offs. did:key: Underlying Technology: Cryptographic key pair. DID Document Storage/Resolution: The DID and DID Document are generated directly from the public key. It does not require writing to any external registry.¹⁸ Resolution occurs locally by converting the public key into a DID Document. Key Characteristics: Simplicity, usability offline, suitable for ephemeral identifiers, peer-to-peer interactions, and testing.²³ Advantages: Maximum decentralization (no registry dependency), free to create. Disadvantages/Limitations: Limited update capabilities (key rotation changes the DID), no mechanism for DID discovery. did:web: Underlying Technology: Existing web infrastructure (DNS, HTTPS, web servers). DID Document Storage/Resolution: The DID Document (a did.json file) is hosted on a web server controlled by the domain owner at a specific path (e.g., https://example.com/.well-known/did.json for did:web:example.com).¹⁷ Resolution occurs via an HTTPS request to this URL. Key Characteristics: Uses existing and widely adopted infrastructure, allows organizations to link their digital identity to their web domain.²⁶ Advantages: Relatively easy to implement for domain owners, human-readable DIDs (if the domain is readable). Disadvantages/Limitations: Dependency on DNS and web server security, centralization within a single domain, possibility of tracking requests to did.json. did:ethr: Underlying Technology: Ethereum blockchain. DID Document Storage/Resolution: Ethereum addresses are used as DIDs. DID Documents are dynamically constructed based on events logged in a special smart contract registry (e.g., ERC1056 ethr-did-registry).²⁷ Key Characteristics: Leverages the security and immutability of the Ethereum blockchain for DID management. Advantages: High degree of decentralization and censorship resistance (properties of Ethereum), ability to link DIDs to existing Ethereum accounts. Disadvantages/Limitations: Transaction costs (gas) for write/update operations on Ethereum, potential scalability issues on the Ethereum mainnet. did:ion: Underlying Technology: A Layer 2 network on top of the Bitcoin blockchain, using the Sidetree protocol and IPFS for storing DID Document data.¹⁹ DID Document Storage/Resolution: DID operations are batched and anchored to the Bitcoin blockchain, while the DID Documents themselves (or their deltas) are stored in IPFS. Resolution involves retrieving data from IPFS and verifying it using information from Bitcoin. Key Characteristics: High scalability (thousands of operations per second), censorship resistance, no special tokens or additional consensus mechanisms.²⁹ Advantages: Combines the security of Bitcoin with high throughput and low operation costs. Disadvantages/Limitations: Architectural complexity (Layer 2, Sidetree, IPFS), dependency on the availability of IPFS nodes. did:iota: Underlying Technology: IOTA's distributed ledger (the Tangle). DID Document Storage/Resolution: DID Documents and their associated metadata are stored directly in Identity objects on the IOTA ledger.³⁰ Key Characteristics: Designed for environments with a high volume of microtransactions and Internet of Things (IoT) devices, with no transaction fees on the IOTA mainnet.³⁰ Advantages: Scalability for IoT, feeless transactions, integration with other IOTA features. Disadvantages/Limitations: Specificity of the IOTA ecosystem, questions about long-term data persistence on the Tangle (depends on permanodes). did:key: Underlying Technology: Cryptographic key pair. DID Document Storage/Resolution: The DID and DID Document are generated directly from the public key. It does not require writing to any external registry.¹⁸ Resolution occurs locally by converting the public key into a DID Document. Key Characteristics: Simplicity, usability offline, suitable for ephemeral identifiers, peer-to-peer interactions, and testing.²³ Advantages: Maximum decentralization (no registry dependency), free to create. Disadvantages/Limitations: Limited update capabilities (key rotation changes the DID), no mechanism for DID discovery. did:key Underlying Technology: Cryptographic key pair. DID Document Storage/Resolution: The DID and DID Document are generated directly from the public key. It does not require writing to any external registry.¹⁸ Resolution occurs locally by converting the public key into a DID Document. Key Characteristics: Simplicity, usability offline, suitable for ephemeral identifiers, peer-to-peer interactions, and testing.²³ Advantages: Maximum decentralization (no registry dependency), free to create. Disadvantages/Limitations: Limited update capabilities (key rotation changes the DID), no mechanism for DID discovery. Underlying Technology: Cryptographic key pair. Underlying Technology: DID Document Storage/Resolution: The DID and DID Document are generated directly from the public key. It does not require writing to any external registry.¹⁸ Resolution occurs locally by converting the public key into a DID Document. DID Document Storage/Resolution: Key Characteristics: Simplicity, usability offline, suitable for ephemeral identifiers, peer-to-peer interactions, and testing.²³ Key Characteristics: Advantages: Maximum decentralization (no registry dependency), free to create. Advantages: Disadvantages/Limitations: Limited update capabilities (key rotation changes the DID), no mechanism for DID discovery. Disadvantages/Limitations: did:web: Underlying Technology: Existing web infrastructure (DNS, HTTPS, web servers). DID Document Storage/Resolution: The DID Document (a did.json file) is hosted on a web server controlled by the domain owner at a specific path (e.g., https://example.com/.well-known/did.json for did:web:example.com).¹⁷ Resolution occurs via an HTTPS request to this URL. Key Characteristics: Uses existing and widely adopted infrastructure, allows organizations to link their digital identity to their web domain.²⁶ Advantages: Relatively easy to implement for domain owners, human-readable DIDs (if the domain is readable). Disadvantages/Limitations: Dependency on DNS and web server security, centralization within a single domain, possibility of tracking requests to did.json. did:web Underlying Technology: Existing web infrastructure (DNS, HTTPS, web servers). DID Document Storage/Resolution: The DID Document (a did.json file) is hosted on a web server controlled by the domain owner at a specific path (e.g., https://example.com/.well-known/did.json for did:web:example.com).¹⁷ Resolution occurs via an HTTPS request to this URL. Key Characteristics: Uses existing and widely adopted infrastructure, allows organizations to link their digital identity to their web domain.²⁶ Advantages: Relatively easy to implement for domain owners, human-readable DIDs (if the domain is readable). Disadvantages/Limitations: Dependency on DNS and web server security, centralization within a single domain, possibility of tracking requests to did.json. Underlying Technology: Existing web infrastructure (DNS, HTTPS, web servers). Underlying Technology: DID Document Storage/Resolution: The DID Document (a did.json file) is hosted on a web server controlled by the domain owner at a specific path (e.g., https://example.com/.well-known/did.json for did:web:example.com).¹⁷ Resolution occurs via an HTTPS request to this URL. DID Document Storage/Resolution: did.json https://example.com/.well-known/did.json did:web:example.com Key Characteristics: Uses existing and widely adopted infrastructure, allows organizations to link their digital identity to their web domain.²⁶ Key Characteristics: Advantages: Relatively easy to implement for domain owners, human-readable DIDs (if the domain is readable). Advantages: Disadvantages/Limitations: Dependency on DNS and web server security, centralization within a single domain, possibility of tracking requests to did.json. Disadvantages/Limitations: did.json did:ethr: Underlying Technology: Ethereum blockchain. DID Document Storage/Resolution: Ethereum addresses are used as DIDs. DID Documents are dynamically constructed based on events logged in a special smart contract registry (e.g., ERC1056 ethr-did-registry).²⁷ Key Characteristics: Leverages the security and immutability of the Ethereum blockchain for DID management. Advantages: High degree of decentralization and censorship resistance (properties of Ethereum), ability to link DIDs to existing Ethereum accounts. Disadvantages/Limitations: Transaction costs (gas) for write/update operations on Ethereum, potential scalability issues on the Ethereum mainnet. did:ethr Underlying Technology: Ethereum blockchain. DID Document Storage/Resolution: Ethereum addresses are used as DIDs. DID Documents are dynamically constructed based on events logged in a special smart contract registry (e.g., ERC1056 ethr-did-registry).²⁷ Key Characteristics: Leverages the security and immutability of the Ethereum blockchain for DID management. Advantages: High degree of decentralization and censorship resistance (properties of Ethereum), ability to link DIDs to existing Ethereum accounts. Disadvantages/Limitations: Transaction costs (gas) for write/update operations on Ethereum, potential scalability issues on the Ethereum mainnet. Underlying Technology: Ethereum blockchain. Underlying Technology: DID Document Storage/Resolution: Ethereum addresses are used as DIDs. DID Documents are dynamically constructed based on events logged in a special smart contract registry (e.g., ERC1056 ethr-did-registry).²⁷ DID Document Storage/Resolution: ethr-did-registry Key Characteristics: Leverages the security and immutability of the Ethereum blockchain for DID management. Key Characteristics: Advantages: High degree of decentralization and censorship resistance (properties of Ethereum), ability to link DIDs to existing Ethereum accounts. Advantages: Disadvantages/Limitations: Transaction costs (gas) for write/update operations on Ethereum, potential scalability issues on the Ethereum mainnet. Disadvantages/Limitations: did:ion: Underlying Technology: A Layer 2 network on top of the Bitcoin blockchain, using the Sidetree protocol and IPFS for storing DID Document data.¹⁹ DID Document Storage/Resolution: DID operations are batched and anchored to the Bitcoin blockchain, while the DID Documents themselves (or their deltas) are stored in IPFS. Resolution involves retrieving data from IPFS and verifying it using information from Bitcoin. Key Characteristics: High scalability (thousands of operations per second), censorship resistance, no special tokens or additional consensus mechanisms.²⁹ Advantages: Combines the security of Bitcoin with high throughput and low operation costs. Disadvantages/Limitations: Architectural complexity (Layer 2, Sidetree, IPFS), dependency on the availability of IPFS nodes. did:ion Underlying Technology: A Layer 2 network on top of the Bitcoin blockchain, using the Sidetree protocol and IPFS for storing DID Document data.¹⁹ DID Document Storage/Resolution: DID operations are batched and anchored to the Bitcoin blockchain, while the DID Documents themselves (or their deltas) are stored in IPFS. Resolution involves retrieving data from IPFS and verifying it using information from Bitcoin. Key Characteristics: High scalability (thousands of operations per second), censorship resistance, no special tokens or additional consensus mechanisms.²⁹ Advantages: Combines the security of Bitcoin with high throughput and low operation costs. Disadvantages/Limitations: Architectural complexity (Layer 2, Sidetree, IPFS), dependency on the availability of IPFS nodes. Underlying Technology: A Layer 2 network on top of the Bitcoin blockchain, using the Sidetree protocol and IPFS for storing DID Document data.¹⁹ Underlying Technology: DID Document Storage/Resolution: DID operations are batched and anchored to the Bitcoin blockchain, while the DID Documents themselves (or their deltas) are stored in IPFS. Resolution involves retrieving data from IPFS and verifying it using information from Bitcoin. DID Document Storage/Resolution: Key Characteristics: High scalability (thousands of operations per second), censorship resistance, no special tokens or additional consensus mechanisms.²⁹ Key Characteristics: Advantages: Combines the security of Bitcoin with high throughput and low operation costs. Advantages: Disadvantages/Limitations: Architectural complexity (Layer 2, Sidetree, IPFS), dependency on the availability of IPFS nodes. Disadvantages/Limitations: did:iota: Underlying Technology: IOTA's distributed ledger (the Tangle). DID Document Storage/Resolution: DID Documents and their associated metadata are stored directly in Identity objects on the IOTA ledger.³⁰ Key Characteristics: Designed for environments with a high volume of microtransactions and Internet of Things (IoT) devices, with no transaction fees on the IOTA mainnet.³⁰ Advantages: Scalability for IoT, feeless transactions, integration with other IOTA features. Disadvantages/Limitations: Specificity of the IOTA ecosystem, questions about long-term data persistence on the Tangle (depends on permanodes). did:iota Underlying Technology: IOTA's distributed ledger (the Tangle). DID Document Storage/Resolution: DID Documents and their associated metadata are stored directly in Identity objects on the IOTA ledger.³⁰ Key Characteristics: Designed for environments with a high volume of microtransactions and Internet of Things (IoT) devices, with no transaction fees on the IOTA mainnet.³⁰ Advantages: Scalability for IoT, feeless transactions, integration with other IOTA features. Disadvantages/Limitations: Specificity of the IOTA ecosystem, questions about long-term data persistence on the Tangle (depends on permanodes). Underlying Technology: IOTA's distributed ledger (the Tangle). Underlying Technology: DID Document Storage/Resolution: DID Documents and their associated metadata are stored directly in Identity objects on the IOTA ledger.³⁰ DID Document Storage/Resolution: Identity Key Characteristics: Designed for environments with a high volume of microtransactions and Internet of Things (IoT) devices, with no transaction fees on the IOTA mainnet.³⁰ Key Characteristics: Advantages: Scalability for IoT, feeless transactions, integration with other IOTA features. Advantages: Disadvantages/Limitations: Specificity of the IOTA ecosystem, questions about long-term data persistence on the Tangle (depends on permanodes). Disadvantages/Limitations: The diversity of DID methods reflects the fact that there is no one-size-fits-all solution suitable for all possible scenarios. The choice of a specific method depends on requirements for security, scalability, transaction cost, level of decentralization, the type of underlying system used, and other factors. This flexibility, however, gives rise to a problem sometimes called "method wars" or "method fragmentation," and creates challenges for interoperability, as wallets and applications must either support many methods or risk being incompatible with part of the DID ecosystem.³² Table 2: Comparative Overview of Popular DID Methods Table 2: Comparative Overview of Popular DID Methods Method Underlying Technology DID Document Storage/Resolution Key Characteristics Advantages Disadvantages/Limitations did:key Cryptographic key pair Generated from a public key, no registry required Simplicity, offline use, for ephemeral IDs, P2P interactions Maximum decentralization, free to create, high privacy Limited updates (key change = new DID), no discovery did:web Web infrastructure (DNS, HTTPS) did.json file on a web server at a known path Uses existing domains, suitable for organizations Relative simplicity for domain owners, human-readable (if domain is) Dependency on DNS and web server, centralization within a domain, trackable requests did:ethr Ethereum blockchain, smart contract (ERC1056) Dynamically built from ethr-did-registry smart contract events Leverages Ethereum's security High decentralization and censorship resistance, linkage to Ethereum accounts Transaction costs (gas), Ethereum scalability did:ion Bitcoin (Layer 1), Sidetree (Layer 2), IPFS Data in IPFS, anchors in Bitcoin High scalability, censorship resistance, no native tokens Bitcoin security + high throughput, low operation cost Architectural complexity, dependency on IPFS nodes did:iota IOTA distributed ledger (Tangle) Stored in Identity objects on the IOTA ledger For IoT, microtransactions, feeless Scalability for IoT, no fees Specificity of the IOTA ecosystem, questions of data persistence on the Tangle Method Underlying Technology DID Document Storage/Resolution Key Characteristics Advantages Disadvantages/Limitations did:key Cryptographic key pair Generated from a public key, no registry required Simplicity, offline use, for ephemeral IDs, P2P interactions Maximum decentralization, free to create, high privacy Limited updates (key change = new DID), no discovery did:web Web infrastructure (DNS, HTTPS) did.json file on a web server at a known path Uses existing domains, suitable for organizations Relative simplicity for domain owners, human-readable (if domain is) Dependency on DNS and web server, centralization within a domain, trackable requests did:ethr Ethereum blockchain, smart contract (ERC1056) Dynamically built from ethr-did-registry smart contract events Leverages Ethereum's security High decentralization and censorship resistance, linkage to Ethereum accounts Transaction costs (gas), Ethereum scalability did:ion Bitcoin (Layer 1), Sidetree (Layer 2), IPFS Data in IPFS, anchors in Bitcoin High scalability, censorship resistance, no native tokens Bitcoin security + high throughput, low operation cost Architectural complexity, dependency on IPFS nodes did:iota IOTA distributed ledger (Tangle) Stored in Identity objects on the IOTA ledger For IoT, microtransactions, feeless Scalability for IoT, no fees Specificity of the IOTA ecosystem, questions of data persistence on the Tangle Method Underlying Technology DID Document Storage/Resolution Key Characteristics Advantages Disadvantages/Limitations Method Method Method Underlying Technology Underlying Technology Underlying Technology DID Document Storage/Resolution DID Document Storage/Resolution DID Document Storage/Resolution Key Characteristics Key Characteristics Key Characteristics Advantages Advantages Advantages Disadvantages/Limitations Disadvantages/Limitations Disadvantages/Limitations did:key Cryptographic key pair Generated from a public key, no registry required Simplicity, offline use, for ephemeral IDs, P2P interactions Maximum decentralization, free to create, high privacy Limited updates (key change = new DID), no discovery did:key did:key did:key Cryptographic key pair Cryptographic key pair Generated from a public key, no registry required Generated from a public key, no registry required Simplicity, offline use, for ephemeral IDs, P2P interactions Simplicity, offline use, for ephemeral IDs, P2P interactions Maximum decentralization, free to create, high privacy Maximum decentralization, free to create, high privacy Limited updates (key change = new DID), no discovery Limited updates (key change = new DID), no discovery did:web Web infrastructure (DNS, HTTPS) did.json file on a web server at a known path Uses existing domains, suitable for organizations Relative simplicity for domain owners, human-readable (if domain is) Dependency on DNS and web server, centralization within a domain, trackable requests did:web did:web did:web Web infrastructure (DNS, HTTPS) Web infrastructure (DNS, HTTPS) did.json file on a web server at a known path did.json file on a web server at a known path did.json Uses existing domains, suitable for organizations Uses existing domains, suitable for organizations Relative simplicity for domain owners, human-readable (if domain is) Relative simplicity for domain owners, human-readable (if domain is) Dependency on DNS and web server, centralization within a domain, trackable requests Dependency on DNS and web server, centralization within a domain, trackable requests did:ethr Ethereum blockchain, smart contract (ERC1056) Dynamically built from ethr-did-registry smart contract events Leverages Ethereum's security High decentralization and censorship resistance, linkage to Ethereum accounts Transaction costs (gas), Ethereum scalability did:ethr did:ethr did:ethr Ethereum blockchain, smart contract (ERC1056) Ethereum blockchain, smart contract (ERC1056) Dynamically built from ethr-did-registry smart contract events Dynamically built from ethr-did-registry smart contract events ethr-did-registry Leverages Ethereum's security Leverages Ethereum's security High decentralization and censorship resistance, linkage to Ethereum accounts High decentralization and censorship resistance, linkage to Ethereum accounts Transaction costs (gas), Ethereum scalability Transaction costs (gas), Ethereum scalability did:ion Bitcoin (Layer 1), Sidetree (Layer 2), IPFS Data in IPFS, anchors in Bitcoin High scalability, censorship resistance, no native tokens Bitcoin security + high throughput, low operation cost Architectural complexity, dependency on IPFS nodes did:ion did:ion did:ion Bitcoin (Layer 1), Sidetree (Layer 2), IPFS Bitcoin (Layer 1), Sidetree (Layer 2), IPFS Data in IPFS, anchors in Bitcoin Data in IPFS, anchors in Bitcoin High scalability, censorship resistance, no native tokens High scalability, censorship resistance, no native tokens Bitcoin security + high throughput, low operation cost Bitcoin security + high throughput, low operation cost Architectural complexity, dependency on IPFS nodes Architectural complexity, dependency on IPFS nodes did:iota IOTA distributed ledger (Tangle) Stored in Identity objects on the IOTA ledger For IoT, microtransactions, feeless Scalability for IoT, no fees Specificity of the IOTA ecosystem, questions of data persistence on the Tangle did:iota did:iota did:iota IOTA distributed ledger (Tangle) IOTA distributed ledger (Tangle) Stored in Identity objects on the IOTA ledger Stored in Identity objects on the IOTA ledger Identity For IoT, microtransactions, feeless For IoT, microtransactions, feeless Scalability for IoT, no fees Scalability for IoT, no fees Specificity of the IOTA ecosystem, questions of data persistence on the Tangle Specificity of the IOTA ecosystem, questions of data persistence on the Tangle 3.3. The Role of Verifiable Credentials (VC) The Link Between DIDs and VCs: The Link Between DIDs and VCs: Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) are two closely related but distinct technologies that are often used together to build self-sovereign identity systems. A DID acts as a cryptographic anchor, providing a unique and verifiable identity for the various participants in the VC ecosystem, such as the issuer, the holder, and, in some cases, the subject of the credential itself.³³ Simply put, a DID answers the question "who are you?" (i.e., provides an identifier), while a VC answers the question "what is said about you (or someone/something)?" (i.e., contains verifiable claims, attributes, or qualifications, such as a university diploma, a driver's license, a certificate of compliance, etc.).³⁴ DIDs are used to anchor public cryptographic keys, which in turn are used to digitally sign VCs by the issuer and to verify these signatures by the verifier. This makes it possible to confirm that the VC was issued by the specified issuer and that its contents have not been altered. DID answers the question "who are you?" VC answers the question "what is said about you (or someone/something)?" Note: Note: The Verifiable Credentials technology is a separate, feature-rich W3C standard that defines the structure, lifecycle, and processing mechanisms for digital claims. A detailed examination of the structure of VCs, their representation formats, and cryptographic protection mechanisms is beyond the scope of this article and will be presented in a separate publication. DID Resolvers Function: Function: A DID Resolver is a software or hardware-software component whose primary function is to take a DID as input and return the corresponding DID Document.¹⁰ This process is called "DID resolution." To perform this function, the resolver must understand the DID syntax and, specifically, be able to extract the DID method name from it. Based on the method name, the resolver determines which DID method specification to use to interact with the corresponding verifiable data registry (e.g., a blockchain, a web server, etc.) where the DID Document is stored or from which it can be generated.⁸ There are both specialized resolvers that support only one or a few specific DID methods, and universal resolvers (such as the Universal Resolver from the Decentralized Identity Foundation - DIF) that aim to support the widest possible range of methods, acting as an aggregator or gateway to various systems.³² DID resolvers are a critically important infrastructure component of the DID ecosystem. They are what make DIDs practically useful, allowing any participant in the system who has a DID to obtain the up-to-date and authentic information (the DID Document) needed to establish trust and interact with the subject of that DID. Without resolvers, DIDs would remain just unique strings with no way to be interpreted or used. All components of the DID ecosystem—the identifier itself, the DID Document, the DID method, and the DID resolver—are closely interconnected and form a single, cohesive system. A DID Document is meaningless without the DID that identifies it. The DID method defines how the DID and DID Document are managed and where (or how) they are stored. The resolver uses information from the DID (namely, the method) to know how to retrieve the DID Document by following the logic defined by the DID method. It is a closed-loop system where each element performs its clearly defined role, ensuring the functioning of the whole. Furthermore, the DID Document is not a static file but a dynamically updatable structure that reflects the current state of the subject's identity (e.g., current keys, available services). The ability to update the DID Document, especially for key rotation or changing service endpoints, is critically important for the long-term security and practical utility of DIDs. The DID Lifecycle Decentralized Identifiers, like any other identifiers, go through a specific lifecycle. The W3C DID Core specification defines a set of standard operations that can be performed on a DID and its associated DID Document: Create, Read/Resolve, Update, and Deactivate.¹⁴ It is important to understand that the specific implementation of these operations and their availability depend on the specification of the particular DID method. Create: This is the initial stage where a new, globally unique DID and its associated initial DID Document are generated. The creation process typically involves generating one or more cryptographic key pairs (private and public). The public keys (or information to derive them) are placed in the DID Document, and the private keys are securely stored by the DID controller.³⁷ For some DID methods, like did:key, the creation process is a purely local cryptographic operation that requires no interaction with any external registry.¹⁸ For other methods, such as those based on a blockchain (did:ethr, did:ion), creation may involve a transaction to register the DID or its anchor on the corresponding registry. Register: For DID methods that rely on a verifiable data registry (e.g., a blockchain or another DLT), after generating the DID and its initial DID Document, it may be necessary to publish or register them on that registry. Only after successful registration does the DID become publicly resolvable, meaning other parties can find its associated DID Document.¹⁴ For methods like did:key or certain configurations of did:peer, this step may be absent, as all the necessary information for resolving the DID Document is contained within the DID itself or is transmitted through other channels. It is important to note that the W3C DID Core specification does not single out "Register" as a separate universal operation, but rather considers it part of the "Create" operation for those methods that require interaction with a registry for the DID to become discoverable by third parties. Resolve: Resolution is the process by which a DID string is used to retrieve its corresponding DID Document.¹⁴ This operation is performed by a DID resolver. The resolver analyzes the DID method specified in the DID and, following the rules of that method, queries the appropriate verifiable data registry to obtain the current version of the DID Document.¹⁴ If the DID does not exist or has been deactivated, the resolver will return a corresponding error or status information. Update: The DID controller can make changes to their associated DID Document. This is a critically important operation for maintaining the currency and security of the identity.¹⁴ Examples of updates include: Rotating cryptographic keys (e.g., replacing old or compromised keys with new ones). Adding, modifying, or removing verification methods. Adding, modifying, or removing service endpoints. Changing the DID controller (if permitted by the method). Like creation, the update operation for many DID methods requires an authorized write to the verifiable data registry. Deactivate: The DID controller can decide to revoke their DID, making it invalid for future interactions.¹⁴ The deactivation process depends on the DID method. It usually involves an update to the DID Document or a special entry in the registry indicating that the DID is no longer active. After deactivation, when an attempt is made to resolve such a DID, the resolver should return information that the DID has been deactivated. This does not necessarily mean the DID or DID Document is deleted from the registry (especially in immutable registries like blockchains), but it signals the termination of its validity. Create: This is the initial stage where a new, globally unique DID and its associated initial DID Document are generated. The creation process typically involves generating one or more cryptographic key pairs (private and public). The public keys (or information to derive them) are placed in the DID Document, and the private keys are securely stored by the DID controller.³⁷ For some DID methods, like did:key, the creation process is a purely local cryptographic operation that requires no interaction with any external registry.¹⁸ For other methods, such as those based on a blockchain (did:ethr, did:ion), creation may involve a transaction to register the DID or its anchor on the corresponding registry. Create: did:key did:ethr did:ion Register: For DID methods that rely on a verifiable data registry (e.g., a blockchain or another DLT), after generating the DID and its initial DID Document, it may be necessary to publish or register them on that registry. Only after successful registration does the DID become publicly resolvable, meaning other parties can find its associated DID Document.¹⁴ For methods like did:key or certain configurations of did:peer, this step may be absent, as all the necessary information for resolving the DID Document is contained within the DID itself or is transmitted through other channels. It is important to note that the W3C DID Core specification does not single out "Register" as a separate universal operation, but rather considers it part of the "Create" operation for those methods that require interaction with a registry for the DID to become discoverable by third parties. Register: did:key did:peer Resolve: Resolution is the process by which a DID string is used to retrieve its corresponding DID Document.¹⁴ This operation is performed by a DID resolver. The resolver analyzes the DID method specified in the DID and, following the rules of that method, queries the appropriate verifiable data registry to obtain the current version of the DID Document.¹⁴ If the DID does not exist or has been deactivated, the resolver will return a corresponding error or status information. Resolve: Update: The DID controller can make changes to their associated DID Document. This is a critically important operation for maintaining the currency and security of the identity.¹⁴ Examples of updates include: Rotating cryptographic keys (e.g., replacing old or compromised keys with new ones). Adding, modifying, or removing verification methods. Adding, modifying, or removing service endpoints. Changing the DID controller (if permitted by the method). Like creation, the update operation for many DID methods requires an authorized write to the verifiable data registry. Update: Rotating cryptographic keys (e.g., replacing old or compromised keys with new ones). Adding, modifying, or removing verification methods. Adding, modifying, or removing service endpoints. Changing the DID controller (if permitted by the method). Like creation, the update operation for many DID methods requires an authorized write to the verifiable data registry. Rotating cryptographic keys (e.g., replacing old or compromised keys with new ones). Adding, modifying, or removing verification methods. Adding, modifying, or removing service endpoints. Changing the DID controller (if permitted by the method). Like creation, the update operation for many DID methods requires an authorized write to the verifiable data registry. Deactivate: The DID controller can decide to revoke their DID, making it invalid for future interactions.¹⁴ The deactivation process depends on the DID method. It usually involves an update to the DID Document or a special entry in the registry indicating that the DID is no longer active. After deactivation, when an attempt is made to resolve such a DID, the resolver should return information that the DID has been deactivated. This does not necessarily mean the DID or DID Document is deleted from the registry (especially in immutable registries like blockchains), but it signals the termination of its validity. Deactivate: Although the W3C defines these general operations, the actual implementation of each stage of the DID lifecycle is deeply dependent on the chosen DID method and its underlying technology. For example, "registration" does not exist for did:key; for did:web, it is the uploading of a did.json file to a web server; and for did:ethr, it is a transaction on the Ethereum blockchain. Similar differences exist for update and deactivate operations. This underscores the importance of understanding the specification of a particular DID method when working with DIDs. did:key did:web did.json did:ethr Most operations in the DID lifecycle revolve around the DID Document. Creation is the formation of the initial DID Document, resolution is its retrieval, update is its modification, and deactivation is the change of its status or how it is resolved. Thus, the DID Document is the central artifact reflecting the current state of a DID, and managing it is the essence of managing the DID. The ability to update the DID Document, especially for key rotation, is a critically important feature for long-term security. However, this also places the responsibility on the DID controller for securely managing the keys capable of authorizing such updates. The compromise of these control keys can lead to a loss of control over the DID, highlighting the importance of robust key management practices. Practical Use Cases for DIDs Decentralized Identifiers have the potential to transform many aspects of digital interaction, offering solutions to enhance security, privacy, and user control over their data. Let's explore some key practical scenarios for their application. Passwordless Authentication One of the most obvious and in-demand areas for DID application is passwordless authentication. Instead of the traditional entry of a username and password, users can log into websites and applications by cryptographically proving ownership of their DID.¹² This typically happens by signing a "challenge" proposed by the service using a private key associated with the user's DID and specified in their DID Document. The service can then verify this signature using the corresponding public key from the DID Document. passwordless authentication This approach eliminates the need to remember and manage multiple passwords, significantly reducing the risks associated with phishing, brute-force attacks, and password database leaks.⁴ For the user, the process becomes more convenient and secure, and for developers, the need to store and protect passwords is eliminated.⁴⁰ Decentralized Identity: The Foundation for Digital Wallets DIDs serve as the foundation for decentralized identity, which is often implemented through digital wallets. These wallets become personal repositories for a user's DIDs, their associated cryptographic keys, and also for Verifiable Credentials (VCs) received from various issuers.³⁴ decentralized identity digital wallets With such a wallet, users gain full control over their identity data.³⁴ They can present their DIDs for identification and selectively disclose information from their VCs upon request from verifying parties.¹³ For example, a user can confirm they are over 18 without revealing their exact date of birth, or prove they have a certain qualification without showing the entire diploma. This implements the principle of data minimization and enhances privacy. Security in the Internet of Things (IoT) The rapid growth in the number of Internet of Things (IoT) devices creates serious security challenges related to their identification, authentication, and authorization. DIDs offer an effective solution for ensuring security in IoT.⁴³ ensuring security in IoT Each IoT device can be assigned a unique, cryptographically secured DID. This allows devices to: Securely authenticate each other before establishing communication. Establish encrypted communication channels using keys from their DID Documents. Verify authorization to perform certain actions or access data. Securely authenticate each other before establishing communication. Establish encrypted communication channels using keys from their DID Documents. Verify authorization to perform certain actions or access data. Using DIDs for device identification helps prevent unauthorized access, device spoofing, and other attacks common in IoT networks.⁸ This is especially important in areas like smart homes, industrial IoT, connected vehicles, and medical devices.⁴⁴ Supply Chain Verification Transparency and traceability in supply chains are critical for ensuring product quality, combating counterfeiting, and confirming compliance with various standards (e.g., ethical sourcing or environmental friendliness). DIDs, combined with Verifiable Credentials, can significantly improve these aspects.³² supply chains DIDs can be assigned to: Each product or batch of goods. Each participant in the supply chain (producer, farmer, processor, logistics company, retailer). Equipment used in the production process. Each product or batch of goods. Each participant in the supply chain (producer, farmer, processor, logistics company, retailer). Equipment used in the production process. Verifiable Credentials linked to these DIDs can contain information about the origin of raw materials, processing stages, transportation conditions, quality certificates, etc.⁴⁷ Any participant in the chain or the end consumer can verify this information by looking up the DID Documents and checking the signatures on the VCs. This creates an immutable and verifiable "digital twin" of the product. e-Government and Healthcare The spheres of e-Government and healthcare have particularly high requirements for security, privacy, and control over personal data. DIDs offer significant advantages here. e-Government healthcare e-Government: Citizens can use DIDs for secure identification when accessing government services online, participating in electronic voting, filing tax returns, and other interactions with government agencies.⁴² This can simplify procedures, reduce bureaucracy, and increase trust in digital government services. Examples include digital identity cards or resident cards based on DIDs.⁴⁸ Healthcare: DIDs allow patients to gain control over their medical data.⁵⁰ A patient can store their medical records (in the form of VCs) in their digital wallet and grant selective access to different doctors or medical institutions as needed. DIDs can also be used to identify healthcare professionals and institutions, ensuring secure information exchange and preventing fraud.¹¹ e-Government: Citizens can use DIDs for secure identification when accessing government services online, participating in electronic voting, filing tax returns, and other interactions with government agencies.⁴² This can simplify procedures, reduce bureaucracy, and increase trust in digital government services. Examples include digital identity cards or resident cards based on DIDs.⁴⁸ e-Government: Healthcare: DIDs allow patients to gain control over their medical data.⁵⁰ A patient can store their medical records (in the form of VCs) in their digital wallet and grant selective access to different doctors or medical institutions as needed. DIDs can also be used to identify healthcare professionals and institutions, ensuring secure information exchange and preventing fraud.¹¹ Healthcare: In all these scenarios, the key role is played by the ability of DIDs to provide cryptographically verifiable identity and return control over data and interactions to the DID subject. This is a fundamental difference from traditional systems, where verification often depends on trust in a central intermediary. Many of the most powerful use cases, such as selective data disclosure or verification of specific attributes, are fully realized only when DIDs are used in conjunction with Verifiable Credentials. DIDs provide the answer to "who?", and VCs provide the answer to "what?" (verifiable claims about that "who"). However, mass adoption of DIDs in any of these scenarios requires not only the technology but also the development of an entire ecosystem: DID/VC issuers, holders with wallets, and verifiers willing to accept and process these new forms of digital artifacts. Challenges and Limitations on the Path to Mass Adoption Despite the significant potential of decentralized identifiers, their widespread adoption faces a number of serious challenges and limitations. These problems span technological, user-related, standardization, regulatory, and governance aspects. Technological: DLT Scalability, Complexity of Key Management and Recovery Scalability of Distributed Ledger Technologies (DLT): Many DID methods, especially those based on first-generation public blockchains (e.g., Bitcoin, Ethereum before significant scalability upgrades), can face performance issues with mass use. High network load can lead to increased transaction confirmation times and rising fees, making frequent DID operations (creation, updates) expensive and slow.⁵ For resource-intensive IoT environments, where data from billions of devices needs to be processed, this can become a critical limitation.⁵² Key Management and Recovery: Secure storage of private cryptographic keys, their regular rotation for security maintenance, and especially the process of recovering access in case of key loss or compromise, represent one of the most difficult problems for users.⁵ Unlike centralized systems where there is a password reset procedure through customer support, in decentralized systems based on the principle of self-sovereignty, losing a private key can mean an irreversible loss of control over the DID and all associated assets and data.⁴³ This requires a high level of technical literacy and responsibility from users, which is a barrier to mass adoption.⁵⁴ Scalability of Distributed Ledger Technologies (DLT): Many DID methods, especially those based on first-generation public blockchains (e.g., Bitcoin, Ethereum before significant scalability upgrades), can face performance issues with mass use. High network load can lead to increased transaction confirmation times and rising fees, making frequent DID operations (creation, updates) expensive and slow.⁵ For resource-intensive IoT environments, where data from billions of devices needs to be processed, this can become a critical limitation.⁵² Scalability of Distributed Ledger Technologies (DLT): Key Management and Recovery: Secure storage of private cryptographic keys, their regular rotation for security maintenance, and especially the process of recovering access in case of key loss or compromise, represent one of the most difficult problems for users.⁵ Unlike centralized systems where there is a password reset procedure through customer support, in decentralized systems based on the principle of self-sovereignty, losing a private key can mean an irreversible loss of control over the DID and all associated assets and data.⁴³ This requires a high level of technical literacy and responsibility from users, which is a barrier to mass adoption.⁵⁴ Key Management and Recovery: User Experience (UX): The Need for Simple and Intuitive Wallets for Non-Technical Users Current implementations of systems based on DIDs and related technologies (e.g., digital wallets) often have a complex and non-intuitive user interface, which deters non-technical users.⁵ The processes of onboarding, generating and backing up keys, understanding the concepts of DIDs, Verifiable Credentials, various DID methods, and the need to give consent for data transfer require significant simplification.⁵⁴ For the mass adoption of DIDs, it is critically important to create wallets and applications that abstract the internal complexity of the technology, providing the user with a simple, understandable, and secure way to manage their digital identity.⁵⁶ Without a quality UX focused on the average person, DIDs risk remaining a technology for enthusiasts and specialists. Standardization and Interoperability: DID Method "Wars" and Ensuring Compatibility Between Different Systems Although the W3C has standardized the DID core (syntax, DID Document data model), there is a large number of different DID methods, each with its own features, advantages, and disadvantages, and relying on different underlying technologies.³² This diversity, on the one hand, provides flexibility, but on the other, creates a risk of ecosystem fragmentation and interoperability problems.⁵² If wallets, applications, and services do not support a wide range of DID methods, or if effective mechanisms for interaction between different methods (e.g., "bridges" or universal resolvers) are not developed, users may find themselves locked into specific ecosystems. This phenomenon is sometimes called "DID method wars," where different groups or companies promote their own solutions, making it difficult to create a single, seamless digital identity space.⁵⁷ Regulatory Issues: Government Recognition of DIDs and Associated Credentials Legal and regulatory uncertainty is a significant obstacle to the widespread adoption of DIDs, especially in areas requiring legal validity, such as e-government, financial services, or official identity verification.⁵ The lack of clear legislative recognition of DIDs and Verifiable Credentials by government agencies and regulators in various jurisdictions slows their adoption.⁵⁷ Although there are initiatives, such as the European eIDAS regulation and the associated European Self-Sovereign Identity Framework (ESSIF), aimed at integrating SSI approaches into the legal field¹, the overall regulatory environment for DIDs is still in its formative stages. Governance: Who Governs the Rules for Specific DID Methods and How For each DID method, especially those dependent on public or permissioned distributed ledgers, governance issues are important.⁵⁷ Who makes decisions about updating the method's specification? How are conflicts resolved or vulnerabilities discovered? Who is responsible for maintaining the security and stability of the underlying infrastructure on which the DID method depends?⁵⁹ The absence of transparent, understandable, and reliable governance models for specific DID methods can undermine trust in them from users, organizations, and regulators alike. The problems listed are not isolated but are closely interrelated. For example, the complexity of key management (a technological problem) directly worsens the user experience. "DID method wars" (a standardization problem) create confusion for users and developers (UX) and hinder regulatory recognition. Even if the technological aspects are solved, the user experience remains the "last mile" for mass adoption: the technology must be not only functional but also intuitive and secure for the non-technical user. Standardization, on the one hand, is critical for interoperability, but on the other, overly rigid or premature standardization at the method level could stifle innovation. "Method wars," while creating problems, are also a sign of an active search for the best solutions. Table 3: Key Challenges and Limitations on the Path to Mass Adoption of DIDs Table 3: Key Challenges and Limitations on the Path to Mass Adoption of DIDs Problem Category Problem Description Example Aspects Potential Solutions Technological Limitations of underlying technologies and complexity of implementing cryptographic aspects. DLT scalability, transaction costs, private key management, access recovery after key loss. Development of Layer 2 solutions, new consensus algorithms, social recovery protocols, hardware wallets, key management abstraction. User Experience (UX) High barrier to entry for non-technical users, complexity of interfaces and concepts. Complicated onboarding, confusing terminology, risk of errors in key management, lack of intuitive applications. Simplification of wallet and application interfaces, educational programs, standardization of user scenarios, process visualization. Standardization & Interoperability Multiple DID methods, risk of ecosystem fragmentation, lack of full compatibility between systems. "DID method wars," need for multi-method support in wallets, complexity of cross-network interactions. Development of universal resolvers, creation of interoperability profiles for DID methods, standards for cross-network "bridges," focus on data-level compatibility (VCs). Regulatory Issues Lack of clear legal status for DIDs and VCs, non-recognition by government bodies, legislative uncertainty. Legal validity of DID-based digital IDs, GDPR/HIPAA compliance, licensing of VC issuers. Dialogue with regulators, development of pilot projects with government participation, creation of industry standards that consider regulatory requirements, legislative adaptation. Governance Opaqueness or absence of governance models for some DID methods and their underlying networks. Who controls the method's development, how decisions on changes are made, ensuring network security. Formation of open communities around DID methods, development of transparent governance procedures, use of DAO-like structures for decentralized governance. Problem Category Problem Description Example Aspects Potential Solutions Technological Limitations of underlying technologies and complexity of implementing cryptographic aspects. DLT scalability, transaction costs, private key management, access recovery after key loss. Development of Layer 2 solutions, new consensus algorithms, social recovery protocols, hardware wallets, key management abstraction. User Experience (UX) High barrier to entry for non-technical users, complexity of interfaces and concepts. Complicated onboarding, confusing terminology, risk of errors in key management, lack of intuitive applications. Simplification of wallet and application interfaces, educational programs, standardization of user scenarios, process visualization. Standardization & Interoperability Multiple DID methods, risk of ecosystem fragmentation, lack of full compatibility between systems. "DID method wars," need for multi-method support in wallets, complexity of cross-network interactions. Development of universal resolvers, creation of interoperability profiles for DID methods, standards for cross-network "bridges," focus on data-level compatibility (VCs). Regulatory Issues Lack of clear legal status for DIDs and VCs, non-recognition by government bodies, legislative uncertainty. Legal validity of DID-based digital IDs, GDPR/HIPAA compliance, licensing of VC issuers. Dialogue with regulators, development of pilot projects with government participation, creation of industry standards that consider regulatory requirements, legislative adaptation. Governance Opaqueness or absence of governance models for some DID methods and their underlying networks. Who controls the method's development, how decisions on changes are made, ensuring network security. Formation of open communities around DID methods, development of transparent governance procedures, use of DAO-like structures for decentralized governance. Problem Category Problem Description Example Aspects Potential Solutions Problem Category Problem Category Problem Category Problem Description Problem Description Problem Description Example Aspects Example Aspects Example Aspects Potential Solutions Potential Solutions Potential Solutions Technological Limitations of underlying technologies and complexity of implementing cryptographic aspects. DLT scalability, transaction costs, private key management, access recovery after key loss. Development of Layer 2 solutions, new consensus algorithms, social recovery protocols, hardware wallets, key management abstraction. Technological Technological Technological Limitations of underlying technologies and complexity of implementing cryptographic aspects. Limitations of underlying technologies and complexity of implementing cryptographic aspects. DLT scalability, transaction costs, private key management, access recovery after key loss. DLT scalability, transaction costs, private key management, access recovery after key loss. Development of Layer 2 solutions, new consensus algorithms, social recovery protocols, hardware wallets, key management abstraction. Development of Layer 2 solutions, new consensus algorithms, social recovery protocols, hardware wallets, key management abstraction. User Experience (UX) High barrier to entry for non-technical users, complexity of interfaces and concepts. Complicated onboarding, confusing terminology, risk of errors in key management, lack of intuitive applications. Simplification of wallet and application interfaces, educational programs, standardization of user scenarios, process visualization. User Experience (UX) User Experience (UX) User Experience (UX) High barrier to entry for non-technical users, complexity of interfaces and concepts. High barrier to entry for non-technical users, complexity of interfaces and concepts. Complicated onboarding, confusing terminology, risk of errors in key management, lack of intuitive applications. Complicated onboarding, confusing terminology, risk of errors in key management, lack of intuitive applications. Simplification of wallet and application interfaces, educational programs, standardization of user scenarios, process visualization. Simplification of wallet and application interfaces, educational programs, standardization of user scenarios, process visualization. Standardization & Interoperability Multiple DID methods, risk of ecosystem fragmentation, lack of full compatibility between systems. "DID method wars," need for multi-method support in wallets, complexity of cross-network interactions. Development of universal resolvers, creation of interoperability profiles for DID methods, standards for cross-network "bridges," focus on data-level compatibility (VCs). Standardization & Interoperability Standardization & Interoperability Standardization & Interoperability Multiple DID methods, risk of ecosystem fragmentation, lack of full compatibility between systems. Multiple DID methods, risk of ecosystem fragmentation, lack of full compatibility between systems. "DID method wars," need for multi-method support in wallets, complexity of cross-network interactions. "DID method wars," need for multi-method support in wallets, complexity of cross-network interactions. Development of universal resolvers, creation of interoperability profiles for DID methods, standards for cross-network "bridges," focus on data-level compatibility (VCs). Development of universal resolvers, creation of interoperability profiles for DID methods, standards for cross-network "bridges," focus on data-level compatibility (VCs). Regulatory Issues Lack of clear legal status for DIDs and VCs, non-recognition by government bodies, legislative uncertainty. Legal validity of DID-based digital IDs, GDPR/HIPAA compliance, licensing of VC issuers. Dialogue with regulators, development of pilot projects with government participation, creation of industry standards that consider regulatory requirements, legislative adaptation. Regulatory Issues Regulatory Issues Regulatory Issues Lack of clear legal status for DIDs and VCs, non-recognition by government bodies, legislative uncertainty. Lack of clear legal status for DIDs and VCs, non-recognition by government bodies, legislative uncertainty. Legal validity of DID-based digital IDs, GDPR/HIPAA compliance, licensing of VC issuers. Legal validity of DID-based digital IDs, GDPR/HIPAA compliance, licensing of VC issuers. Dialogue with regulators, development of pilot projects with government participation, creation of industry standards that consider regulatory requirements, legislative adaptation. Dialogue with regulators, development of pilot projects with government participation, creation of industry standards that consider regulatory requirements, legislative adaptation. Governance Opaqueness or absence of governance models for some DID methods and their underlying networks. Who controls the method's development, how decisions on changes are made, ensuring network security. Formation of open communities around DID methods, development of transparent governance procedures, use of DAO-like structures for decentralized governance. Governance Governance Governance Opaqueness or absence of governance models for some DID methods and their underlying networks. Opaqueness or absence of governance models for some DID methods and their underlying networks. Who controls the method's development, how decisions on changes are made, ensuring network security. Who controls the method's development, how decisions on changes are made, ensuring network security. Formation of open communities around DID methods, development of transparent governance procedures, use of DAO-like structures for decentralized governance. Formation of open communities around DID methods, development of transparent governance procedures, use of DAO-like structures for decentralized governance. The Future of DIDs and Their Role in Web3 Decentralized Identifiers (DIDs) are positioned not just as an improvement to existing identification systems, but as a fundamental building block for the next-generation internet—Web3. Their unique properties open up new possibilities for building more trusted, private, and user-centric digital interactions. The Foundation for Web3: DIDs as the Basis for Reputation, DAO Access Control, and dApp Interaction Web3 aims to create a decentralized internet where users control their own data and assets. DIDs play a key role in realizing this vision: Decentralized Reputation Systems: In Web3, reputation becomes a valuable asset. DIDs can serve as cryptographic anchors for reputation data, which can be represented as Verifiable Credentials or Soulbound Tokens (SBTs).⁶¹ This allows users to accumulate and port their reputation (e.g., transaction history in DeFi, participation in DAO governance, contributions to projects) across different platforms and decentralized applications (dApps) without being dependent on centralized evaluators. Access Control in DAOs (Decentralized Autonomous Organizations): DAOs require reliable mechanisms for identifying members, distributing voting rights, and managing resources. DIDs can be used to identify DAO members, and their associated attributes (e.g., reputation, token holdings, roles) can be used to implement weighted voting or grant differentiated access rights.⁶¹ This helps combat Sybil attacks (creating multiple fake accounts to manipulate voting). Interaction with dApps: DIDs simplify and secure user interaction with dApps. Instead of creating a separate account for each dApp, a user can use their DID for authentication.⁵³ This also allows dApps to request necessary data (in the form of VCs) from the user based on their DID, with the user retaining control over what information is disclosed.⁵³ Decentralized Reputation Systems: In Web3, reputation becomes a valuable asset. DIDs can serve as cryptographic anchors for reputation data, which can be represented as Verifiable Credentials or Soulbound Tokens (SBTs).⁶¹ This allows users to accumulate and port their reputation (e.g., transaction history in DeFi, participation in DAO governance, contributions to projects) across different platforms and decentralized applications (dApps) without being dependent on centralized evaluators. Decentralized Reputation Systems: Access Control in DAOs (Decentralized Autonomous Organizations): DAOs require reliable mechanisms for identifying members, distributing voting rights, and managing resources. DIDs can be used to identify DAO members, and their associated attributes (e.g., reputation, token holdings, roles) can be used to implement weighted voting or grant differentiated access rights.⁶¹ This helps combat Sybil attacks (creating multiple fake accounts to manipulate voting). Access Control in DAOs (Decentralized Autonomous Organizations): Interaction with dApps: DIDs simplify and secure user interaction with dApps. Instead of creating a separate account for each dApp, a user can use their DID for authentication.⁵³ This also allows dApps to request necessary data (in the form of VCs) from the user based on their DID, with the user retaining control over what information is disclosed.⁵³ Interaction with dApps: DIDs solve one of the fundamental problems of early Web3—the lack of a reliable and sovereign identity layer—paving the way for more complex, personalized, and trusted interactions on a decentralized network. Enhancing Privacy: Mentioning that DIDs are often used in conjunction with advanced cryptographic methods like Zero-Knowledge Proofs (ZKPs) for maximum confidentiality While DIDs themselves promote privacy by allowing the use of different identifiers for different contexts, their combination with other cryptographic technologies can provide an even higher level of confidentiality. Specifically, this refers to Zero-Knowledge Proofs (ZKPs). Zero-Knowledge Proofs (ZKPs) ZKPs allow one party (the prover) to convince another party (the verifier) that a certain statement is true, without revealing any information beyond1 the fact of the statement's truth.⁶² In the context of DIDs and Verifiable Credentials, this means a user can prove they possess a certain attribute (e.g., that they are over 21, or that they have a diploma from a specific university) without revealing the attribute itself (the exact date of birth or the name of the university).⁶³ The DID serves to identify the owner of the VC, and the ZKP serves to privately prove claims from that VC. W3C specifications related to VCs provide for support of various cryptographic schemes that enable ZKPs, such as BBS+ signatures or Selective Disclosure JWTs (SD-JWT).⁶³ Zero-Knowledge Proofs (ZKP) are a powerful and rapidly developing area of cryptography with a wide range of potential applications far beyond just identity. The principles of how ZKPs work, their various types, and the specific mechanisms for integrating them with DIDs and VCs represent a complex topic that deserves a separate, detailed examination in a future article. The Evolution of Standards: A Brief Look at the Development of W3C Specifications and Community Work The standards concerning decentralized identifiers are not static. They are actively evolving thanks to the efforts of the World Wide Web Consortium (W3C) and a broad international community of developers, researchers, and companies.⁶⁴ The DID Core specification, which defines the basic architecture, data model, and syntax of DIDs, has progressed from Working Drafts to the status of a W3C Recommendation, which is the highest level of standard maturity.⁶⁵ However, the work does not stop there: new versions of specifications are emerging (e.g., DID Core 1.0 has evolved to version 1.1, incorporating new requirements and clarifications), and extensions and related standards are being developed, such as specifications for various DID methods, DID Resolution protocols, and, of course, standards for Verifiable Credentials.⁷ This evolutionary process reflects the living nature of the technology. As new use cases emerge, problems with existing approaches are identified, and cryptographic methods advance, the standards are adapted and improved.⁸ The active participation of the community in discussions, testing, and developing implementations plays a key role in this process. While DIDs are the foundation for Web3 identity, their full potential (e.g., in reputation systems, DAO governance, or private dApps) is unlocked only in synergy with other Web3 technologies like Verifiable Credentials, Zero-Knowledge Proofs, smart contracts, and decentralized storage systems. The DID is the "ignition key," but the entire Web3 "car" is needed for full movement. The development of W3C standards is largely driven by practical needs and problems identified during real-world implementations, such as scalability, user experience, and interoperability. As Web3 applications become more complex, it is likely that the specialization of DID methods and related tools for specific niches (DeFi, SocialFi, GameFi) will continue, rather than attempting to create one universal DID stack for everything. Conclusion The technology of Decentralized Identifiers (DIDs) represents a significant step forward in the evolution of digital identity, offering a solution to many of the fundamental problems inherent in traditional centralized and federated models. Summary: DIDs are not just a new technology, but a paradigm shift in digital identity management As has been shown in this article, DIDs are not another incremental improvement, but a fundamental paradigm shift in how we create, manage, and use our digital identities.⁴² They return control over identity data directly to users, allowing them to become the true sovereigns of their digital essence. This approach, known as Self-Sovereign Identity (SSI), is the opposite of models where identifiers and their associated data are controlled by third-party providers.³ fundamental paradigm shift DIDs solve the key problems of modern identification systems: they eliminate dependency on central authorities, reduce the risks of mass data breaches through decentralization, combat identity fragmentation, and provide users with tools to manage their privacy. Final Takeaway: DIDs lay the foundation for a more secure, private, and user-centric internet where trust is created cryptographically, not through intermediaries. They are the core around which ecosystems are built using technologies like Verifiable Credentials and ZKPs. Decentralized Identifiers lay the groundwork for building a more secure, private, and user-centric internet—key characteristics of the Web3 concept.¹² In such an ecosystem, trust between interacting parties is established not based on the reputation of centralized intermediaries, but on the basis of cryptographic proofs that can be verified by any participant. more secure, private, and user-centric internet DIDs are the core around which more complex and powerful identity and data management systems are formed. They serve as the starting point for the use of Verifiable Credentials (VCs), which allow users to obtain, store, and present verifiable claims about themselves, and Zero-Knowledge Proofs (ZKPs), which provide the ability to prove the truth of these claims without disclosing excess information.¹⁵ These complementary technologies, which will be discussed in detail in subsequent articles, multiply the potential of DIDs. Verifiable Credentials (VCs) Zero-Knowledge Proofs (ZKPs) The adoption of DIDs and SSI not only solves existing problems but also opens up opportunities for creating entirely new types of applications and business models that were unimaginable in a centralized world. This is not just about fixing the old, but about creating a new digital landscape. However, the success of this paradigm shift will largely depend on educational efforts aimed at explaining the benefits and working principles of these technologies to both developers and end-users. Despite the enormous potential, the transition from current identity models to a world dominated by DIDs will be a long and gradual process, requiring the overcoming of technological, user, regulatory, and business challenges. It is a marathon, not a sprint, but its goal is the creation of a truly sovereign and trusted digital future for all.