Deactivate DID
If the DID is no longer used or needed, it can be deactivated. After that, the DID will be in an invalid state and cannot be used for authentication and any other DID-related operations.
The deactivating operation of DID typically contains two situations:
The controller of DID actively deactivates DID
The private key is lost, but the DID declares an authorization Key, which can be deactivated by the principal
The results of deactivating DID through these two forms are the same, which will directly lead to the permanent invalidation of DID.
DID is Deactivated by Controller
The DID controller can deactivate the DID with the default authentication key corresponding to it, and only with the default authentication key can the deactivating operation be launched. An example is as follows:
For customized DID, deactivating the DID can be launched by any valid controller. Similarly, the deactivating operation needs to be signed by the controller’s default authentication key. For example:
The Principal Deactivates the DID
This method is only applicable to primitive DID, and isn't necessary to set a principal for customized DID because of the controller.
For security reasons, primitive DID can set one or more trusted principals, which is embodied by specifying the trusted entrustment key. Based on the principle of minimum authorization, this delegation key can only be used to deactivate DID. The goal is that after the DID controller loses the key, the principal can invalidate the DID, thus reducing the potential safety hazard caused by the key loss.
Last updated