Decentralized Identifiers (DIDs) Overview

• Decentralized Identifiers (DIDs) are globally unique, cryptographically verifiable identifiers that operate without reliance on a central authority.
• DIDs resolve to DID Documents containing public keys, service endpoints, and delegation details that enable authentication and secure interactions.
• DID systems underpin Self-Sovereign Identity, IoT, smart grids, academic publishing, and supply chains, offering enhanced privacy, security, and interoperability.

A Decentralized Identifier (DID) is a globally unique, cryptographically verifiable identifier whose creation and control are not reliant on a central authority, registry, or service. Defined by a fixed URI scheme, DIDs are foundational to Self-Sovereign Identity (SSI) systems, where entities—including individuals, devices, organizations, and products—independently generate, manage, and use identifiers anchored in decentralized frameworks. Each DID resolves to a DID Document, which serves as the authoritative metadata resource for verification, authentication, and service discovery. The robust cryptographic binding between identities and control material (public keys, proofs) is a critical aspect, supporting authentication, selective disclosure, and control delegation across a wide variety of domains, from IoT and smart grids to academic publishing and supply chains.

1. Formal Structure and Resolution

A DID is defined by the URI scheme

$$\mathtt{did:}\langle\textit{method}\rangle:\langle\textit{method-specific\_identifier}\rangle$$

where:

• did: is the universal prefix,
• <method> specifies the particular DID method (e.g., key, ethr, web, sw),
• <method-specific_identifier> is the payload whose structure depends on the method.

Resolution of a DID yields a DID Document (often JSON-LD), which contains fields such as:

• Public keys (for authentication, assertion, encryption, or agreement),
• Service endpoints (e.g., URLs for secure messaging, credential exchange),
• Controllers and delegates (entities authorized to perform management operations).

A canonical example is

did:key:z6MkhaXgBZD...38x74tKLGpbnnEGta2doK

where the identifier is a base58/base64 or other cryptographic encoding, and

DIDDoc(DID) = { PK_i, Auth, ServiceEndpoints, ... }

is anchored either in a registry (blockchain, DLT, DHT) or, in registry-less methods, disseminated by other means (Hoops et al., 2023, Fotiou et al., 29 Apr 2025). In the case of lightweight or registry-less specifications (did:self), the thumbprint or cryptographic digest of the public key is directly embedded in the identifier, and the document is reconstructed from cryptographically self-contained material (e.g., JWTs, X.509) (Fotiou et al., 29 Apr 2025).

2. Cryptographic Foundations and Operational Security

DIDs leverage asymmetric cryptography for the authentication and proof of control over identities. The critical operation is: $$\text{Signature} = \mathrm{Sign}(\text{private\_key}, \text{data})$$ with the corresponding public key (declared in the DID Document) used for verification. This signature paradigm enables:

• Proof-of-possession protocols,
• Key rotation,
• Delegation and group control (multi-signature, weighted voting, smart contract governance) (Garzon et al., 21 Mar 2025, Segat et al., 8 Jul 2025).

Some DID methods introduce additional privacy-preserving primitives:

• Zero-Knowledge Proofs (ZKPs) for attribute assertions (e.g., membership, conflict-of-interest avoidance) (Pino et al., 2023, Al-Sabahi et al., 3 Aug 2025).
• Ring signatures for unlinkability of the signing key among a set (the “ring”) (Kasimatis et al., 8 Mar 2024):

$$\text{id} = \text{base58}\left(\text{first}_{256}\left(H\left(\mathsf{pk}_s \parallel r \parallel \mathtt{ring} \parallel \mathsf{pk}_1 \parallel \cdots \parallel \mathsf{pk}_n\right)\right)\right)$$

The cryptographic soundness of DID-based schemes depends not only on the hardness of the underlying primitives (e.g., ECDSA/Ed25519, SHA-2) but also on the correct use of challenge–response protocols, nonce handling, and the prevention of vulnerabilities such as dictionary attacks (Halpin, 2020, Parameswarath et al., 2022).

3. Governance, Delegation, and Ledger Anchoring

The governance of DIDs—i.e., determining how and by whom DID Documents can be updated—is a major topic of current research and standardization. The specification supports both independent and group control models (Garzon et al., 21 Mar 2025, Segat et al., 8 Jul 2025):

• Independent Control: A single controller (the DID subject) directly signs updates.
• Delegated Control: Authority to update the DID Document is granted to deputies, whose credentials are listed in the controller/capabilityInvocation sections (Garzon et al., 21 Mar 2025).
• Group Control: Authorization of updates occurs only after multi-party consensus, realized technically by configurable smart contracts (e.g., n-of-m approval, weighted or turnout-sensitive voting) anchored on distributed ledgers (Segat et al., 8 Jul 2025).

Formalization of control policies is critical for applications involving multiple stakeholders or organizational contexts. For robustness, on-chain governance contracts may support state transitions (CREATED, ANCHORED, UPDATED, INVALIDATED), and fine-grained delegation (to individual fields or capabilities) can be modeled via delegation tokens or verifiable credentials (Garzon et al., 21 Mar 2025).

Ledger anchoring of DID Documents (using blockchains, DLTs, or DHTs) is fundamental for tamper-evidence and global availability. However, registry-less approaches such as did:self avoid such dependencies, embedding proofs directly and allowing arbitrary dissemination channels (Fotiou et al., 29 Apr 2025). Each model presents unique trade-offs between auditability, availability, privacy, and attack surface.

4. Application Domains and Protocol Integration

DIDs now underpin diverse application domains:

Domain	DID Application Example	Methodological Feature
SSI / Individuals	User-centric ID, digital wallets, ZKPs	Selective disclosure
IoT	Device identity, Swarm/CBOR-DI, resource constraints	Minimal metadata schemas
Smart Grid / EV	Key exchange, privacy-preserving VC presentation	ZKPs, key recovery
Academic Publishing	Authorship attestation, peer review accountability	Blockchain registry, ZKPs
Supply Chain & DPP	Digital product passports, lifecycle tracking	Controller field, VCs
Network Security	Zero Trust, context- and relationship-aware control	Dynamic relationship tuples

Notable protocol integrations shaped by DID specifications include:

• Secure TLS authentication via DID Link, replacing X.509 CA root-of-trust with DID-anchor verification and post-handshake VC presentations (Garzon et al., 13 May 2024).
• Swarm DID and DIoTComm, where identity and secure communication are feasible on highly bandwidth-constrained IoT networks via efficient binary encoding (CBOR/COSE) (Fedrecheski et al., 2021).
• Zero-Trust and distributed access control frameworks, leveraging DIDs as primary identity handles for cryptographically validated, contextual policy enforcement (Ahmadi, 14 Jan 2025, Kyriakidou et al., 11 Jun 2025).

In several designs, the use of permanent distributed storage (e.g., Arweave, IOTA Tangle) further extends availability and tamper-resistance, with registry performance and cost estimates quantified via empirical benchmarks and cost formulas (Claudio et al., 2023, Dragnoiu et al., 18 Dec 2024, García et al., 21 Oct 2024).

5. Privacy, Security, and Critique

The decentralization of identifier control brings a nuanced security and privacy landscape:

• Enhanced Security: Elimination of single points of compromise; cryptographic proofs render many credential-based attacks ineffective (Othman et al., 2017, Ahmadi, 14 Jan 2025).
• Data Minimization & User Sovereignty: Only minimal, necessary information is disclosed; privacy controls are enabled via selective disclosure, ZKPs, and ring signatures (Pino et al., 2023, Kasimatis et al., 8 Mar 2024, Al-Sabahi et al., 3 Aug 2025).
• Potential Weaknesses: Risks include correlation across persistent, globally visible DIDs, improper or insufficient cryptographic primitives, and issues in data serialization (which can open signature exclusion/graph attacks) (Halpin, 2020).
• Scalability and Interoperability Challenges: Methods for resolving or updating DID Documents must address throughput and caching strategies for performance at scale (Claudio et al., 2023, Segat et al., 8 Jul 2025).
• Regulatory Compliance: Architectural designs increasingly incorporate GDPR-oriented features such as the separation of public data (DID Documents) from sensitive claims (VCs), user consent, and revocation mechanisms (Dragnoiu et al., 18 Dec 2024, Ahmadi, 14 Jan 2025).

A persistent critique is the risk of “cryptography theater”—referring to the invocation of cryptographic primitives or decentralization claims without rigorous specification or security proofs. This is especially pertinent in early deployments, such as immunity passports, where incomplete anonymization, incomplete canonicalization, and questionable incentive alignment can create new attack surfaces and privacy threats, sometimes termed “identity totalitarianism” (Halpin, 2020).

6. Taxonomy and Method Selection

Due to the proliferation and divergence of DID methods, a comprehensive taxonomy facilitates informed selection and adoption (Hoops et al., 2023). Seven critical dimensions are identified:

• Use Case Scope (general/specific)
• Registry Technology (DLT, DHT, Web Service, self-contained)
• Deployment Requirement (none, independent, coordinated)
• Operation Support (create/resolve, CRUD)
• Explicit Cost Model (free, write fee, recurring, hybrid)
• Identifier Format (human-readable, not human-readable)
• DID Document Capabilities (minimal, basic, keys, services, arbitrary)

This taxonomy enables practitioners to rapidly eliminate unsuitable options and focus on methods that align with feature, deployment, and operational criteria. Case studies demonstrate mapping of specific method classes—such as expressive lightweight DIDs, public DLT DIDs, or registry-less methods (did:self)—to technical requirements and cost models.

7. Open Questions and Future Directions

Advancing DID technology involves addressing several open areas:

• Governance: Specification and enforcement of multi-party (group) control, programmable on-chain mechanisms, and cost-sharing among controllers (Garzon et al., 21 Mar 2025, Segat et al., 8 Jul 2025).
• Standardization and Interoperability: Harmonization of DID methods, credential binding, update policies, and cross-ledger mobility (Hoops et al., 2023, Segat et al., 8 Jul 2025).
• Quantum-Resistant Schemes: Assessment and migration to hash-based or lattice-based primitives in light of quantum attacks, especially for group membership proofs (Pino et al., 2023).
• Performance and Usability: Optimization of ledger resolution, binary encoding for constrained environments, robust key rotation, and user-friendly wallet implementations (Fedrecheski et al., 2021, Mazzocca et al., 4 Feb 2024).
• Privacy-Enhancing Technologies: Adoption of advanced ZKP systems, minimal disclosure credentialing, and revocation mechanisms compatible with privacy legislation (Dragnoiu et al., 18 Dec 2024, Al-Sabahi et al., 3 Aug 2025).
• Applied Security Analysis: Comprehensive threat models for governance attacks, replay and correlation resistance, and resistance to side-channel or network-level attack vectors.

A plausible implication is that future digital identity landscapes will require DIDs to natively support programmable, multi-stakeholder governance, privacy-centric selective disclosure, and robust cross-domain verifiability anchored in both cryptographic soundness and responsible operational standards.

---

References:

(Othman et al., 2017, Halpin, 2020, Fedrecheski et al., 2021, Garzon et al., 2021, Parameswarath et al., 2022, Claudio et al., 2023, Pino et al., 2023, Hoops et al., 2023, Chamon et al., 2023, Mazzocca et al., 4 Feb 2024, Kasimatis et al., 8 Mar 2024, Garzon et al., 13 May 2024, García et al., 21 Oct 2024, Dragnoiu et al., 18 Dec 2024, Ahmadi, 14 Jan 2025, Garzon et al., 21 Mar 2025, Fotiou et al., 29 Apr 2025, Kyriakidou et al., 11 Jun 2025, Segat et al., 8 Jul 2025, Al-Sabahi et al., 3 Aug 2025)