DID Update

A critical security operation that deactivates a compromised or outdated verification method and replaces it with a new one. This is often done by updating the verificationMethod list and adjusting related references in the authentication or assertionMethod sections. Proper key rotation maintains the DID's persistent identifier while changing the underlying cryptographic control.

• Mechanism: The update is authorized by the current, still-valid private key(s).
• Importance: Mitigates the impact of key loss or compromise, a core benefit of DIDs over static identifiers.

Modifies the service array in the DID Document to point to new decentralized web nodes (DWN), hosted agents, or other service interfaces. This allows the DID's associated services—like encrypted messaging, data storage, or credential exchange—to be relocated or upgraded without changing the identifier.

• Common Updates: Changing the URL for a DIDComm mediator, updating a linked personal data store, or adding a new VC issuance service.
• Flexibility: Decouples service location from identity, enabling user-controlled data sovereignty.

An advanced operation that transfers control of the DID from one entity or set of keys to another. This involves updating the controller property in the DID Document. The exact mechanics are defined by the DID method; some may require authorization from the new controller as part of the update transaction.

• Use Case: Transferring asset ownership linked to a DID, or changing organizational control of an institutional DID.
• Contrasts with: Deactivation, which renders the DID unusable. Controller change keeps it active under new management.

Grants or removes authorization for third parties to act on behalf of the DID controller. This is managed through capabilities like OAuth2-style authorization details or UCANs (User Controlled Authorization Networks) referenced in the DID Document. An update might add a new verification method with a specific capability invocation scope.

• Example: Granting a cloud backup service the capability to write to your personal data store for 30 days.
• Granular Control: Enables least-privilege, auditable delegation without sharing primary private keys.

The final update operation that permanently renders a DID unusable. The DID method specifies the mechanism, often involving setting a flag or removing all verification methods and service endpoints. The DID identifier remains on the ledger but its document indicates it is deactivated, preventing future updates or usage in proofs.

• Critical for: Responding to irreversible key loss, retiring an identity, or complying with legal "right to erasure" requests.
• Permanence: In most blockchain-based methods, this operation is irreversible.

The primary security mechanism for a DID update is authorization, enforced by cryptographic proofs. The update must be signed by a verification method (e.g., a private key) currently authorized in the DID Document. This enables secure key rotation, where compromised keys can be revoked and replaced with new ones, a fundamental practice for long-lived identities.

DID methods must protect against:

• Replay Attacks: An attacker re-submitting a valid, old update transaction to revert the DID to a previous, possibly compromised state.
• Race Conditions: Concurrent update requests creating an ambiguous final state. Mitigations include using monotonic counters (e.g., updateId), timestamps, or blockchain-native transaction nonces to ensure strict versioning and order.

The security model depends on the underlying verifiable data registry (e.g., a blockchain). Considerations include:

• Network Consensus: Updates are only final after blockchain finality.
• Transaction Fees: Update failures due to insufficient gas or fee market volatility.
• Smart Contract Risks: For smart contract-based DIDs (e.g., ERC-725/734), bugs in the contract logic could lock or hijack the identifier.

A secure DID Document should pre-define recovery mechanisms to prevent permanent loss:

• Recovery Keys/Committees: Separate keys with the sole power to replace all other keys, held in cold storage or by trusted parties.
• Delegated Attorneys: Temporary authorization grants for specific agents to perform updates, which must be explicitly revocable. Without these, a lost primary key renders the DID immutable and unusable.

The update transaction itself can leak sensitive metadata:

• Transaction Graph Analysis: On public blockchains, the update's origin address can link a DID to other activities, potentially deanonymizing the controller.
• Document Change Tracking: Observers can monitor all historical states, revealing patterns in service endpoints or key changes. Privacy-preserving techniques like zk-proofs or using private data storage are often necessary complements.

After an update, verifiers must be able to cryptographically verify:

1. The authenticity of the new DID Document (valid signature).
2. The legitimacy of the update operation per the registry's rules.
3. The document's current state against the registry. This chain of trust, from the registry root to the current document, is essential for non-repudiation and preventing fraudulent state assertions.

The primary reason for a DID Update is key rotation, where the cryptographic keys associated with a DID are replaced. This is a critical security practice to mitigate the risk of key compromise. The update transaction replaces the old public key in the DID Document with a new one, while the immutable DID itself remains constant.

• Security Hygiene: Proactively rotates keys before they expire or are suspected to be weak.
• Post-Compromise Recovery: Essential for regaining control if a private key is lost or stolen.

DID Updates allow the management of service endpoints listed in the DID Document. These endpoints are URLs for interacting with the DID subject, such as for exchanging verifiable credentials.

• Dynamic Services: Update the location of a credential repository, messaging service, or linked resource.
• Protocol Upgrades: Change endpoints to support new communication protocols or API versions without changing the user's core identity.

The mechanics of a DID Update are defined by the DID Method specification governing the identifier. Different blockchain and ledger systems have unique update procedures.

• Ethereum (ethr): A smart contract call from the current controller's address.
• Sovereign (did:key): Not updatable; a new DID must be created.
• ION (Bitcoin): Anchoring a new Update Operation to the Bitcoin blockchain via the Sidetree protocol.
• Veramo: Uses a plugin architecture to execute updates across multiple supported DID methods.

A valid DID Update requires cryptographic proof of authorization. The update transaction must be signed by a key currently authorized in the DID Document or by a designated delegate.

• Controller Proof: The update payload is signed with the private key corresponding to a verificationMethod or authentication public key in the current DID Document.
• Immutable Record: The signed update request becomes part of the blockchain's immutable transaction history, providing a verifiable audit trail of all changes.

DID Methods implement rules to handle conflicting updates and permanent deactivation.

• Last-Write-Wins: Most ledger-based methods use a monotonic counter or timestamp to ensure the latest valid update is authoritative.
• Deactivation: A special type of update that revokes all keys and services, rendering the DID permanently inactive. This is irreversible and prevents any future updates.