Each DID maps to a DID document. A DID document is necessary to capture and store information about a digital identity represented by a DID. It includes verification methods, such as cryptographic keys, to validate the authenticity of the identity. Additionally, it enables interactions and services associated with the identity in a decentralized and secure manner.
A ZK DID Document has several attributes. Let's take a look at them:
ZK DID adheres to the guidelines of W3C. If you have any questions regarding specific attributes, please refer to https://www.w3.org/TR/did-core/#did-document-properties.
@Context: This is a JSON-LD that can be a string or a list containing a mix of strings and/or ordered maps. The serialized value of @context should be the JSON String "https://www.w3.org/ns/did/v1" or a JSON Array where the first item is the JSON String "https://www.w3.org/ns/did/v1".id: This is a unique ID identifier that begins with the ZK DID Method did:zk:or did:zk:<non-evm-chain-name>: (based on the network).controller: This is a list of valid ZK DIDs or a single ZK DID. It includes one or more ZK DIDs that have control over this DID Document.verificationMethod: This is a list of Verification Methods, which store public keys that can verify signatures or encrypt information. It includes the following fields:
id: A unique field, a string that adheres to the DID Syntax, typically in the form did:zk:0xabcd#key-0.type: The type of the current key. The supported types are:
publicKeyMultibase: The public key is serialized as a multibase.There are also several optional attributes that a ZK DID Document can include:
authentication (optional): This is used to verify the identity of the DID subject. It's commonly used for website logins or participation in any "challenge-response" protocol.assertionMethod (optional): This represents how the DID subject should make assertions, such as for issuing Verifiable Credentials (VCs) or for issuing and revoking attestations.keyAgreement (optional): This is used to establish encrypted channels and transmit confidential information. It's used for point-to-point encryption of received and sent messages.capabilityInvocation (optional): This specifies the verification method that the DID subject uses to invoke cryptographic capabilities, such as the authorization to update the DID document.capabilityDelegation(optional): This is used when the DID subject delegates cryptographic capabilities to another party, such as delegating the ability to access a specific HTTP API to subordinates.services(optional): This represents the communication method with the DID Subject. Any type of service can be included, usually a URL link. It refers to the method of communication between the DID subject and related entities.To help solidify your understanding, here are examples of an EVM Based ZK DID Document and a Non-EVM-based ZK DID Document:
EVM-Based' DID Document
{
"@context": [ "<https://www.w3.org/ns/did/v1>"],
"id": "did:zk:0x11f8b77F34FCF14B7095BF5228Ac0606324E82D1",
"controller": [ "did:zk:0x11f8b77F34FCF14B7095BF5228Ac0606324E82D1" ],
"verificationMethod": [
{
"id": "did:zk:0x11f8b77F34FCF14B7095BF5228Ac0606324E82D1#key-0",
"controller": "did:zk:0x11f8b77F34FCF14B7095BF5228Ac0606324E82D1",
"type": "EcdsaSecp256k1VerificationKey2019",
"publicKeyMultibase": "zgz4zgTUcbvduVZ1Jf3MNMeVeRYP2eiKDJnY7A6PCq3ew"
},
{
"id": "did:zk:0x11f8b77F34FCF14B7095BF5228Ac0606324E82D1#key-1",
"controller": "did:zk:0x11f8b77F34FCF14B7095BF5228Ac0606324E82D1",
"type": "X25519KeyAgreementKey2019",
"publicKeyMultibase": "zEi6rdNHidYZdHyvKYX9sdKka32o6Xq5kP1umoL3Hv1mL"
}
],
"authentication": [ "did:zk:0x11f8b77F34FCF14B7095BF5228Ac0606324E82D1#key-0" ],
"assertionMethod": [ "did:zk:0x11f8b77F34FCF14B7095BF5228Ac0606324E82D1#key-0" ],
"keyAgreement": [ "did:zk:0x11f8b77F34FCF14B7095BF5228Ac0606324E82D1#key-1" ],
"capabilityInvocation": [ "did:zk:0x11f8b77F34FCF14B7095BF5228Ac0606324E82D1#key-0" ],
"capabilityDelegation": [ "did:zk:0x11f8b77F34FCF14B7095BF5228Ac0606324E82D1#key-0" ],
"service": []
}
Non-EVM-Based DID Document