Last updated
Was this helpful?
Last updated
Was this helpful?
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.
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
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.
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.
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
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
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.
Endpoint: /1.0/deactivate
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
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.
recommendation
specification
guide
Authors
Daev Mithran
ADR Stage
ACCEPTED
Implementation Status
In Progress
Start Date
2023-01-30
Last Updated
2023-01-30
