DID Deactivation

Deactivation is initiated by the DID's controller using a cryptographically signed deactivate operation submitted to the underlying verifiable data registry (e.g., a blockchain). This operation updates the DID Document's status, signaling to all verifiers that the identifier is no longer valid. The controller's private key is required, ensuring only authorized parties can perform this action.

• Primary Method: Update to the DID's state on its ledger.
• Authorization: Requires the controller's signature.
• Outcome: The DID Document is tombstoned or marked deactivated.

Once a deactivation transaction is confirmed on the underlying decentralized network, the state change is immutable and final. It cannot be reversed by the original controller or any other party, as the registry's consensus rules prevent modification of historical states. This provides a strong, non-repudiable record of the identifier's lifecycle.

• Permanence: The deactivated status is written permanently to the ledger.
• Non-Reversibility: The identifier cannot be reactivated; a new DID must be created.
• Audit Trail: The deactivation event is timestamped and publicly verifiable.

Verifiers must check the current state of a DID Document before trusting it. After deactivation, any authentication attempt using the DID (e.g., signing a Verifiable Credential) will fail because resolvers will return the deactivated status. Systems must implement active status checking rather than caching credentials indefinitely.

• Resolver Role: DID resolvers fetch the current, deactivated document.
• Verifier Duty: Applications must resolve the DID at the time of verification.
• Security Impact: Prevents use of compromised or retired identities.

Deactivation is distinct from key rotation. Key rotation updates the cryptographic keys in a DID Document while keeping the identifier itself active and relationships intact. Deactivation terminates the identifier entirely. It is a more severe action used for key loss, compromise, or identity retirement.

• Key Rotation: Changes authentication keys; DID remains valid.
• Deactivation: Terminates the DID; all associated keys are invalidated.
• Use Case: Employed when recovery is impossible or undesired.

Deactivating a DID severs its connection to all linked resources, such as Verifiable Credentials, service endpoints, and decentralized storage pointers. Credentials issued to the deactivated DID become unusable, as the issuer's signature can no longer be validated against the now-invalid DID. This necessitates credential re-issuance to a new, active DID.

• Credential Revocation: All VCs tied to the DID are effectively revoked.
• Service Disruption: serviceEndpoint entries in the DID Doc are unreachable.
• Data Orphans: Data referenced by the DID may become inaccessible.

Some DID methods specify governance frameworks or recovery mechanisms that can trigger deactivation under specific conditions, such as a multi-sig agreement or a court order. These are defined in the DID method specification. Social recovery schemes or guardian networks may also hold the capability to deactivate a DID if the primary controller is unavailable.

• Method-Specific Rules: Defined by the DID method (e.g., did:ethr, did:ion).
• Contingency Plans: Allows deactivation without the primary key.
• Regulatory Compliance: Can enable authorized third-party revocation.

Key revocation disables a specific public key within a DID's key list, while DID deactivation renders the entire DID document and all its keys permanently invalid. Deactivation is the final, non-reversible step in the DID lifecycle, often executed by a designated deactivation key or a quorum of controllers. This is distinct from key rotation, which replaces a compromised key with a new one.

A best practice is to pre-define a dedicated deactivation key in the DID document, held offline or in a secure hardware module. This key's sole purpose is to sign the final deactivation transaction, preventing its misuse for routine operations. The pattern ensures that even if operational keys are compromised, an attacker cannot permanently deactivate the DID without the separate deactivation key, preserving forensic evidence and recovery options.

To prevent malicious deactivation, implement multi-signature (multisig) controls requiring multiple controller approvals. Use timelocks or challenge-response protocols to add a delay before deactivation takes effect, allowing for intervention. For DIDs representing high-value assets or legal entities, consider using a decentralized court or on-chain governance as a final arbiter for deactivation requests, moving the decision beyond a single point of failure.

Deactivation should be a documented part of a DID's lifecycle policy. Before deactivation, ensure all verifiable credentials issued to the DID are revoked or have expired to prevent orphaned attestations. Establish clear recovery procedures for scenarios like lost keys, which may involve using backup keys or invoking a social recovery module, to avoid unnecessary deactivation. Plan for the archival of the deactivated DID's history for audit purposes.

Systems that rely on a DID for authentication or credential verification must actively check the DID's status on its underlying ledger or resolver service. After deactivation, any signature verification using that DID will fail. Relying parties should implement logic to cache and respect status lists or direct resolver responses indicating a DID is deactivated, immediately rejecting any new interactions or credentials presented.

Beyond specific methods, deactivation patterns depend on the Verifiable Data Registry. Common implementations include:

• Smart Contract Function Call: A call to a deactivate(DID) function.
• State Flag Update: Flipping a boolean flag in a ledger state tree.
• Tombstone Entry: Appending a final, signed tombstone transaction.
• Time-Locked Recovery: Using a pre-committed timelock to allow a grace period before permanent deactivation.

The core data structure of a DID, containing the public keys, authentication protocols, and service endpoints that define the identity. Deactivation typically involves modifying this document to revoke its verification methods.

• Key Components: id, verificationMethod, authentication, service.
• Immutable Record: The final, deactivated state is permanently recorded on the underlying verifiable data registry (e.g., a blockchain).

The decentralized system (e.g., a blockchain, distributed ledger, or peer-to-peer network) that anchors and stores DID Documents. It provides the tamper-evident layer necessary for trust.

• Examples: Ethereum, Bitcoin, Sovrin, ION.
• Role in Deactivation: The deactivation transaction (e.g., updating the DID Document) is submitted to this registry, making the state change globally verifiable and irreversible.

The technical specification defining how a specific type of DID is created, resolved, updated, and deactivated on a particular verifiable data registry. Each blockchain or network has its own method.

• Examples: did:ethr:, did:ion:, did:key:.
• Critical Function: The method's specification dictates the exact cryptographic procedure (e.g., submitting a signed transaction from a controller key) required to successfully deactivate a DID.

The entity (person, organization, or autonomous software) that possesses the private keys authorized to make changes to a DID Document, including its deactivation. Control is established cryptographically, not by a central authority.

• Key Concept: A DID can have multiple controllers for redundancy.
• Deactivation Authority: Only a current controller can authorize the deactivation operation by providing a valid cryptographic signature.

Distinct but related concepts in credential and identity management.

• Deactivation: Permanently renders the entire DID and its document unusable. It's an identity-level operation.
• Revocation: Invalidates a specific Verifiable Credential issued by that DID, often by updating a revocation registry. The issuing DID itself remains active and can issue new credentials.

The process of retrieving a DID Document from a verifiable data registry using a DID resolver. This is how applications discover the current state and keys of a DID.

• Post-Deactivation: A resolver will return a DID Document with a deactivated property set to true and no valid verification methods, signaling the DID is permanently inactive.
• Universal Resolver: A tool that can resolve DIDs across multiple different DID methods.