Architecture Decision Record (ADR) detailing cheqd's implementation of its DID Registrar.
Last updated
Was this helpful?
Status
Category
Status
Authors
Daev Mithran
ADR Stage
ACCEPTED
Implementation Status
Implemented
Start Date
2023-01-30
Last Updated
2023-01-30
Summary
The defines how DIDs are created and read from ledger. According to the , DID methods are expected to provide .
The is designed to implement the for method to enable create/update/deactivate DID operations easily.
The also supports the creation of 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.
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
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
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.
{
"jobId": "37e4c98e-d876-4e7b-b113-20ae3620174a",
"resourceState": {
"did": "b84817b8-43ee-4483-98c5-f03760816411",
"state": "action",
"action": "signPayload",
"description": "Please sign the following payload with the keys in verificationMethod of the DID used in the path and add the signingResponse in secret",
"signingRequest": [
{
"kid": "did:cheqd:testnet:b84817b8-43ee-4483-98c5-f03760816411#key-1",
"type": "Ed25519VerificationKey2020",
"alg": "EdDSA",
"serializedPayload": "CgtIZWxsbyBXb3JsZBIkYjg0ODE3YjgtNDNlZS00NDgzLTk4YzUtZjAzNzYwODE2NDExGiRjYjk1MGUyNy0yZDNmLTQzOWEtYjA1Yy03ZjZmOTMzMTJiM2IiDFJlc291cmNlTmFtZTIMVGV4dERvY3VtZW50"
}
],
"secret": {
"signingResponse": [
"e.g. { verificationMethodId: did:cheqd:testnet:qsqdcansoica#key-1, signature: aca1s12q14213casdvaadcfas }"
]
}
}
}
The cheqd DID Registrar only supports the , considering the security and scalability of the registrar. The workflow for all the operations follows the protocol below:
Endpoint: /1.0/create Provide a DID Document payload according to the in the request body.
