DID

DID Protocol Main Architecture

As conceptualized and standardized by the W3C, the Decentralized Identifiers, or DIDs, are a new type of identifier that enables verifiable, decentralized digital identity.

Before diving into the DID World, let's read the overview of DID architecture and the relationship between the basic components.

A DID may represent an entity - for example a person, an organization, or even a machine. A Decentralised Identifier (DID) is a string uniquely identifying each user. The DID can contain multiple different keys for purposes such as encryption, signature, authentication, etc.

Narrative Description

☝️ Click Here To Expand

Six internally-labeled shapes appear in the diagram, with labeled arrows between them, as follows. In the center of the diagram is a rectangle labeled DID URL, containing small typewritten text 'did:example:123/path/to/rsrc/. At the center top of the diagram is a rectangle labeled, 'DID', containing small typewritten text 'did:example:123'. At the top left of the diagram is an oval, labeled 'DID Subject'. At the bottom center of the diagram is a rectangle labeled, 'DID document'. At the bottom left is an oval, labeled, 'DID Controller'. On the center right of the diagram is a two-dimensional rendering of a cylinder, labeled, 'Verifiable Data Registry'. From the top of the 'DID URL' rectangle, an arrow, labeled 'contains', extends upwards, pointing to the 'DID' rectangle. From the bottom of the 'DID URL' rectangle, an arrow, labeled 'refers, and dereferences, to', extends downward, pointing to the 'DID document' rectangle. An arrow from the 'DID' rectangle, labeled 'resolves to', points down to the 'DID document' rectangle. An arrow from the 'DID' rectangle, labeled 'refers to', points left to the 'DID subject' oval. An arrow from the 'DID controller' oval, labeled 'controls', points right to the 'DID document' rectangle. An arrow from the 'DID' rectangle, labeled 'recorded on', points downards to the right, to the 'Verifiable Data Registry' cylinder. An arrow from the 'DID document' rectangle, labeled 'recorded on', points upwards to the right to the 'Verifiable Data Registry' cylinder.

To get more details of DID architecture components, or to know more about the terminology of DID, you can reach out for Credential Manifest by DIF and Decentralized Identifiers (DIDs) v1.0 by W3C

ZK DID Method

ZK DID Method Name

The namestring that shall identify this DID method is: zk

A DID that uses this method MUST begin with the following prefix: did:zk. Per the DID specification, this string MUST be in lowercase.

The remainder of the DID, after the prefix, is specified below.

ZK DID Method Specific Identifier

For now, the ZK DID method specific identifiers are categorized as two DID types, EVM-based DID and Non-EVM-based DID.

EVM-based DIDs

A ZK EVM-based DID has the following structure:

zk-did  = "did:zk:" + <user-ethereum-address> 
user-ethereum-address = "0x" 40*HEXDIG

Non-EVM-based DIDs

A ZK Non-EVM-based DID has the following structure:

zk-did  = "did:zk:" + <non-evm-chain-name>  + [ ":" + <user-address> ]
non-evm-chain-name = "sui" | "aptos" | ...
user-address = [a-zA-Z0-9]{1,64}

ZK DID Examples

The example DID above resolves to a DID document. A DID document contains information associated with the DID, such as ways to cryptographically authenticate a DID controller.

The DID ecosystem is based on public key infrastructures where only the owner of the private key has full authorization of the DID. This is similar to blockchain-based systems, in which the users control their assets. This leads to the following issues regarding the system when in use:

  • Recovering a lost private key is extremely difficult;

  • Once your private keys are stolen, malicious acts like impersonation may cause 'you' to misbehave.

As described above, a DID is bound to an entity. So, the user could identify themselves with DID, the developers may distinguish them via DID. We design the API (DID Request Method) for developers to get user DID.

DID-Keys

A DID can be resolved to a DID document stored in a Decentralized Data Registry (e.g. a blockchain). This document contains several keys: a signing key, an encryption key, etc., and optionally a link to a DID service endpoint. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject. Each DID document contains information regarding cryptographic material, verification methods, or service endpoints, which the document provides a set of mechanisms enabling a DID subject to prove ownership of control of the DID.

Currently, two public key and signing algorithms are supported:

The construction of DID Document

{ 
 "@context":
    " -------- content --------",
 "id": [
    " -------- content --------"
 ],
 "controller": [
    " -------- content --------"
 ],
 "verificationMethod": [
    " -------- content --------"
 ],
 "authentication": [
    " -------- content --------"
 ],
 "assertionMethod": [
    " -------- content --------"
 ],
 "keyAgreement": [
    " -------- content --------"
 ],
 "capabilityInvocation": [
    " -------- content --------"
 ],
 "capabilityDelegation": [
    " -------- content --------"
 ],
 "service": [
    " -------- content --------"
 ]
}

We offer several APIs for the usage of DID-Keys, please check the API (DID-Keys Method) for more specification.

Last updated