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
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 }"
]
}
}
}
