DID and Document

DID

Elastos DID supports two DID formats. The first is primitive DID, which uses the ID sidechain address encoded by Bitcoin-style Base58 - the ID string is case-sensitive. The second is customized DID, which is also unique - this will be discussed in the next chapter.

Primitive DID is just an identifier which can be verified by cryptography. It's important to note that DID is a string, where the most fundamental aspect is the key system associated with this string. All related contents of DID are relevant to the identifier - that is, the corresponding contents (such as document and credential) can be found through the DID identifier.

Document

More detailed information of DID is carried by DID Document, such as encrypted information, verification methods and service points. Moreover, DID is represented by DID Document in the chain.

The Elastos DID SDK provides that the DID generated by root identity is presented in the form of DID Document, and it is the simplest DID Document.

If you want DID Document to contain more information, you can operate it through DID Document builder, such as adding public key, deleting voucher, etc., and finally get the desired DID Document through seal operation.

The verification method is contained in DID Document, and the inclusive public key is the carrier of it. DID can sign the data with the private key and verify the signature with the public key in DID Document to ensure that the data has not been tampered with.

DID Document must contain a main key, which is cryptographically verifiable with the DID string.

The public key is used for digital signature, encryption and other operations, the main purpose of which is to realize identity authentication or establish secure communication with service endpoints. In addition, the public key can be used for DID authorization and delegation, as well as used to verify the legality of the DID CRUD operation.

Authentication is a mechanism by which entities can prove that they are associated with DID by encryption. The authentication attribute can specify which DID’s public keys can be used for authentication.

Authorization is a mechanism for explaining how to perform actions on behalf of DID topic. Entrustment refers to the mechanism that DID topic can authorize others to act on their behalf. This is especially important for the DID security aftermath in the case of DID key loss. When the subject can no longer access its key or the key is leaked, the trusted third party authorized by the DID holder can declare to disable the DID, thus prohibiting some malicious behaviors caused by the key leakage.

The authorization and entrustment of Elastos DID only supports the necessary minimum authorization, that is, authorizing a trusted third party to disable the target DID, and does not support other operations.

Besides publishing authentication and authorization mechanism, another main purpose of DID document is to publish the service endpoint corresponding to DID topic. The service endpoint can represent any type of service that the principal wants to announce, including decentralized identity management services for further discovery, authentication, authorization or interaction.

For the sake of safety, the DID topic of Elastos has an effective period, the longest effective period can be set to 5 years, and users can set it to a shorter effective period according to their own needs. A DID topic that exceeds the effective period will be recognized as an invalid DID topic by the DID parser.

Based on ID side chain, the operations related to Elastos DID document storage need to be operated in the client that supports ID side chain. Primitive DID needs to use the authentication public key corresponding to DID topic to launch a transaction for itself. Customized DID can use the public key corresponding to DID topic or the holder’s authentication public key to do the transaction. However, if the customized DID is out of service, DID topic authorization and entrusted DID public key are allowed to initiate related operations.