🟠ADR 004: DID Registrar
Architecture Decision Record (ADR) detailing cheqd's implementation of its DID Registrar.
Status
Authors
Daev Mithran
ADR Stage
ACCEPTED
Implementation Status
Implemented
Start Date
2023-01-30
Last Updated
2023-01-30
Summary
The did:cheqd
method ADR defines how DIDs are created and read from ledger. According to the W3C DID Core specification, DID methods are expected to provide standards-compliant methods of DID and DID Document ("DIDDoc") production.
The cheqd DID Registrar is designed to implement the DIF Registrar specification for did:cheqd
method to enable create/update/deactivate DID operations easily.
The cheqd DID Registrar also supports the creation of DID-Linked Resources for example, schemas, credential definitions, status lists, trust registries and logos.
Architecture
The DID create/update/deactivate functions raise architectural questions around key management, since they typically involve the generation and use of private keys and other secrets.
The DID registrar can operate in the following modes:
Internal Secret Mode
External Secret Mode
Client Managed Secret Mode ✔️
Internal Secret Mode
In this mode, the DID Registrar is responsible for generating the DID controller cryptogprahic keys used in DID operations. Therefore, a DID Registrar used in this mode is considered a highly trusted component which should be fully under the control of a DID controller. If it is operated as a remotely hosted service, secure connection protocols such as TLS, DIDComm, etc. MUST be used.
External Secret Mode
In this mode, the DID Registrar does not itself have access to the cryptographic keys used in DID operations, but it has a way of accessing an external wallet in order to perform cryptographic operations such as generating signatures.
Client Managed Secret Mode
In this mode, the DID Registrar does not itself have access to the cryptographic keys used in DID operations, but it will ask the client to perform operations such as generating keys and signatures in a separate action from using the Registrar.
The cheqd DID Registrar only supports the Client Managed Secret Mode, considering the security and scalability of the registrar. The workflow for all the operations follows the protocol below:

In the above diagram you can see the following steps
Request Operation
The client requests a DID operation providing the required fields
Return JobId and Serialized Payload
The registrar responds with a JobId and a base64 encoded serialized payload
The serialized payload should be signed by all the verificationMethods belonging to the controllers of the DID Document
Submit JobId and SigningResponse
Submit the JobId and the SigningResponse's to the same api
Validate signature and Complete Operation
The registrar validates the signature for the provided DID Document
Submits the DID operation request to the network
DID Operations
Create
Endpoint: /1.0/create
Provide a DID Document payload according to the w3c did core specification in the request body.
The payload can also be created using our helper endpoint /1.0/did-document
, which requires the following options to construct the DID Document payload
Verification Method Type
Method Specific Algorithm
Network
PublicKey Hex encoded string
Update
Endpoint: /1.0/update
Only setDidDocument operation is supported in the cheqd-did-registrar. To update a DID Document, fetch the body of the DID Document you want to change from the DID Resolver, make the relevant updates and pass it to the request operation.
Deactivate
Endpoint: /1.0/deactivate
Resource Operations
Create
Endpoint: /1.0/{:did}/create-resource
Provide an existing DID as the path parameter, and the request body with resource name, type and base64 encoded data
References
W3C Decentralized Identifiers (DIDs) recommendation
DIF DID Registrar specification
Last updated
Was this helpful?