Decentralized Identifier (DID)

Unlike traditional identifiers (email addresses, usernames) that depend on a central provider like Google or a government, a DID is fully sovereign. It is registered on a distributed ledger or decentralized network, meaning no single organization can take it away, deactivate it, or hold it hostage. This removes the single point of failure and the risk of unilateral censorship, which is critical for long-lived content provenance records.

A DID is fundamentally a cryptographic primitive. The identifier itself resolves to a DID Document containing public keys. The controller—who holds the corresponding private key—can prove ownership without a third party.

• Authentication: Prove you are the DID controller.
• Signing: Cryptographically sign content credentials to establish non-repudiation.
• Key Rotation: Update keys in the DID Document without changing the persistent identifier, a vital security property for long-term content signing.

Once created, a DID is designed to be a persistent, long-lived identifier. It does not need to change if the underlying cryptographic keys are rotated or if the service provider changes. This permanence is essential for content provenance, where an attribution chain must remain verifiable for years or decades. The identifier remains stable while its controlling state evolves, ensuring the integrity of the historical record.

A DID is not just a string; it's a dereferenceable URI. Resolving a DID returns a standard DID Document—a JSON-LD file that acts as the identity's control plane. This document lists:

• Public keys for verification.
• Service endpoints for interaction (e.g., where to send verifiable credentials).
• Authentication protocols. This mechanism decouples the identifier from the infrastructure, enabling dynamic, machine-readable trust.

DIDs are governed by the W3C Decentralized Identifiers specification, ensuring they work across different networks, blockchains, and software stacks. This standardization prevents vendor lock-in. A DID created on one method (e.g., did:web for web domains) can be understood and verified by any system adhering to the DID Core specification. This is the foundation for a globally interoperable content provenance ecosystem.

The did:method syntax allows for an extensible architecture. Different methods define how DIDs are created, read, and updated on a specific verifiable data registry.

• did:web: Leverages existing web infrastructure.
• did:key: A self-contained, ephemeral method for testing.
• did:ethr: Anchored to the Ethereum blockchain. This flexibility lets content provenance systems choose the trust model and infrastructure that fits their specific security and cost requirements.

The process of replacing an old public key with a new one in a DID Document without changing the persistent identifier itself. This is essential for long-lived content signing, as it allows an organization to recover from key compromise or upgrade to stronger algorithms while maintaining a continuous, unbroken chain of custody for all assets signed historically under that DID.