DID Specification
Last updated
Last updated
This document assumes that the readers already have some knowledge of W3C standards. For more information about the W3C DID (Decentralized Identity Document) aspect, readers can refer to this document: W3C DID Core Specification. (https://www.w3.org/TR/did-core/)
In this section, let's review the W3C standard's introduction to DID (Decentralized Identifier). DID represents a verifiable decentralized digital identity identifier, characterized by its globally unique and distinct nature. This concept is different from that of an Identity. An Identity emphasizes the concept tied to an individual, while an Identifier emphasizes a symbol or a sign. For example, an ID card can be seen as an Identity, whereas the unique ID number on the card is the Identifier - the specific element used to distinguish one person from another.
Now, let's get acquainted with the key components that make up the DID system:
DID and DID URL: A Decentralized Identifier, or DID, consists of three parts: the scheme header 'did', the DID method name, and a unique identifier specified by the DID method. The specific structure is illustrated in Figure 2.
In zCloak's DID design scheme, we have introduced our own DID method named "zk," hence the ZK DID. The identifier in this method is represented by a blockchain address. In our system, this results in two forms of DID presentation:
DID for EVM (Ethereum Virtual Machine) Ecosystem: This is similar to did:zk:0xE5b8641d32a434BF3B5E6Ea6AFfdA1B56c558eea. Here, the zk method is combined with an EVM-compatible blockchain address.
DID for Non-EVM Ecosystems: For ZK DIDs that are not part of the EVM ecosystem, the format is slightly different, such as did:zk:sui:0xE5b8641d32a434BF3B5E6Ea6AFfdA1B56c558eea. In this case, an additional segment (sui in this example) is included to specify the particular non-EVM blockchain or network.
A DID URL is an extension of the DID syntax, which includes additional components like paths, queries, and fragments. These are used to facilitate the location of specific resources. In the context of ZK DID, the most common form of DID URL is one that includes a fragment. For example, did:zk:0xE5b8641d32a434BF3B5E6Ea6AFfdA1B56c558eea#key-0. In ZK DID, such a URL is used to pinpoint a verification method, typically for executing various cryptographic functions.
DID Subject：DID Subject: The DID subject is the entity that is identified by the DID. It refers to the entity represented by the DID, which might or might not be the actual controller of the DID. In DID documents, this is indicated by the id attribute:
DID Document: A DID document contains information about the DID, specifying the verification methods and services related to interactions with the DID subject. In the context of ZK DID, the document primarily expresses the verification methods associated with the DID subject, which typically include various public and private keys for different scenarios.
DID Controller: The DID controller is the entity that actually controls the DID, and this controller has the capability to modify the DID document. It's important to note that a DID can have multiple controllers, and the DID subject can be the controller of the DID or one of its controllers. In ZK DID, the design aligns the DID controller with the DID subject as a single entity. This means that the ZK DID has only one controller, who is also the subject of the ZK DID. In a DID document, the controller is identified using the controller attribute:
Verifiable Data Registry (VDR): A VDR is a system designed to return the corresponding DID document based on a given DID. It can be any type of carrier, such as a database or some underlying systems. In the design of ZK DID, we use a combination of off-chain database caching and on-chain perpetual storage with Arweave to store the mapping relationships between DIDs and DID documents.
Based on the components described above, we can derive a DID architecture and a diagram illustrating the relationships between these components:
In the aforementioned diagram, we can see that the DID represents the DID subject, and structurally, the DID is a part of the DID URL, but it serves as a unique identifier for the DID subject. The most crucial content related to the DID is carried within the DID document. The mapping and linking relationship between the DID and the DID document are managed and stored by the Verifiable Data Registry (VDR). Considering that the DID subject may not always be the actual controller of the DID document, the role of the DID controller is distinctly outlined.
In DID architecture, the role of the DID document is pivotal, and understanding its concepts is fundamental to grasping the entire system. This section will introduce the core fields in the DID document, as understanding these will help in comprehending various actions related to DID and its interactions with VCs (Verifiable Credentials).
Id: This field is used to specify the DID of a particular DID subject.
controller：The actual controller of the DID, who is authorized to make changes to the DID document. In the design of ZK DID, both the id and controller fields use the DID of the DID subject.
verificationMethod：This is a set of cryptographic verification methods for specific scenarios, essentially a list of public keys that can be used to verify signatures and encrypt information. The value of this field includes the following sub-fields:
id: Presented as a DID fragment.
controller: The actual DID of the DID controller.
type: The type of the current key. Currently supported types include EcdsaSecp256k1VerificationKey2019, Ed25519VerificationKey2020, and X25519KeyAgreementKey2019.
publicKeyMultibase: The serialized public key in MULTIBASE data format.
For example, a verificationMethod entry might look like this:
authentication (optional)：This relationship specifies how the DID subject can authenticate themselves, commonly used for logging into websites or participating in challenge-response protocols. If present, it must be a collection of one or more verification methods. In ZK DID, it's referenced by the id of a verification method, for example:
assertionMethod (optional)：This relationship explains how the DID subject can express VC Claims, generally used in scenarios where an Attester issues a verifiable credential. Like authentication, it must be a collection of one or more verification methods if present, referenced by id in ZK DID, for example:
keyAgreement (optional): This relationship is used to establish encrypted communication channels for transmitting encrypted information. If present, it should be a collection of one or more verification methods, referenced by id in ZK DID, for example:
capabilityInvocation (optional): This relationship indicates capabilities or permissions that can be invoked, such as executing specific operations or accessing certain resources, which could be external. For example, it specifies the methods used to update the DID document. In ZK DID, it's also a collection of one or more verification methods, referenced by id, for example:
capabilityDelegation (optional)：This relationship is used to delegate cryptographic capabilities to another party, such as delegating access to a specific HTTP API to a subordinate. It specifies the verification methods for the delegate and, like the others, is a collection of one or more verification methods in ZK DID, referenced by id, for example:
In the W3C introduction to DID, the use of the keyAgreement key is described as constructing a message channel between DID and DID, in which the keyAgreement key pairs of the message sender and receiver are used, and the process involves the ECDH (Elliptic-curve Diffie-Hellman Key Exchange) process, which is shown in the following figure:
First of all, it is clear that the Message channel is set up for transferring VC, VP and other data between DIDs. After clarifying the purpose, we can see from the above figure that when the sender encrypts the data, it will first use its own keyAgreement private key and the receiver's keyAgreement public key to compute a shared key k, and then encrypt the message to be delivered by this shared key k, and then send the encrypted message to the receiver. After receiving the encrypted data, the receiver will first use its own keyAgreement private key and the sender's keyAgreement public key to calculate a shared key k, and then decrypt the encrypted message with the shared key. The above process is the underlying principle of the Message channel between DIDs.
EVM-based DID in ABNF:
non-EVM-based DID in ABNF:
ZK DID Document:
