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.

Overview of DID architecture and the relationship of the basic components. See also: narrative description.

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.

Core Component	Definition
DIDs and DID URLs	A Decentralized Identifier, or DID, is a URI composed of three parts: the scheme did:, a method identifier, and a unique, method-specific identifier specified by the DID method. DIDs are resolvable to DID documents.
DID subjects/holder	The subject/holder of a DID is, by definition, the entity identified by the DID. The DID subject/holder might also be the DID controller.
DID controllers	A DID controller is an entity that is authorized to make changes to a DID document. The process of authorizing a DID controller is defined by the DID method.
DID documents	DID documents contain information associated with a DID. They typically express verification methods, such as cryptographic public keys, and services relevant to interactions with the DID subject.
Issuer	Issuers are entities that issue credentials to a Holder.
Claim	An assertion made about a Subject. Used as an umbrella term for Credential, Assertion, Attestation, etc.
Verifiable Credential	A standard data model and representation format for cryptographically-verifiable digital credentials as defined by the W3C Verifiable Credentials specification [VC-DATA-MODEL].

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

did	type	description
did:zk:0x51fA67337...82EB6a9B22A	EVM-based DID	a did which relates to a brand new Ethereum address -- '0x51fA67337...82EB6a9B22A'
did:zk:sui:0xd5059a902ad02b...7ceaf7d6	Non-EVM-based DID	a did which relates to a brand new Non-EVM-based address -- '0xd5059a902ad02b...7ceaf7d6'

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:

• Ed25519 -- the EdDSA signature scheme using SHA-512 (SHA-2) and Curve25519.

• Secp256k1 with the ECDSA algorithm -- defined in Standards for Efficient Cryptography (SEC) (Certicom Research).

• X25519 -- is an elliptic curve Diffie-Hellman key exchange using Curve25519. It allows two parties to jointly agree on a shared secret using an insecure channel.

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.