Update or deactivate a DID
Users are able to update DID Documents for various reasons, such as to include a new section or to rotate the Verification Method keys within the DID Document.
With the /did/update
API, users are able to input either:
The section of the DID Document they would like to update; or
The full updated DID Document body.
Users are also able to deactivate DID Documents to prevent further updates and to provide client applications the relevant information that the DID Document is no longer actively used.
A /did/deactivate
request must be signed by all of the Verification Method keys listed in the DID Document.
Create a DID using the did:cheqd method
To create a cheqd DID (did:cheqd
) and associated DID Document there are two ways of building the payload for the request:
Make sure you have set up your account with cheqd Studio and are logged in, using our guide below:
Using the /did/create
API, users have two options for creating a did:cheqd
DID and associated DID Document on-ledger:
Filling out a simple form using the application/x-www-url-form-encoded
option within an API client of your choice.
Compiling a DID Document body yourself using the application/json
option within an API client of your choice.
This is the easiest way to create DIDs on cheqd and is recommended for users who are not overly familiar with compiling DID Documents.
Using the application/x-www-url-form-encoded
option, users are able to choose between the following variables to compile your DID:
From this request, the Credential Service will automatically create and publish a DID and associated DID Document to the ledger and return it as a response.
Instead of generating a DID Document using simple parameters, you can create a fully formatted DID Document yourself. Before, submitting a manually created DID, you will need to have created a set of identity keys to input the key material into the DID document.
Use the /key/create
API to generate a new keypair within the Credential Service key management store. Copy the "publicKeyHex".
To simplify this process of formatting a DID Document using your own keys, we've created a Helper Tool in our DID Registrar here. Simply paste in your publicKeyHex and choose the variables to compile your DID Document template.
Within the /did/create
JSON payload, paste the response of your DID Document template, with your own signing keys.
Request format:
Hit execute on the API below to create your did:cheqd
DID and associated DID Document.
After creating a DID or multiple DIDs, users can list all the created DIDs associated with their account. Using the /did/list
API.
Below are a list of alternatives for creating cheqd DIDs.
Resolve a DID to fetch the associated DID Documet
A user is able to input a DID (string) as a request format and resolve the DID to fetch the associated DID Document, DID Resolution Metadata and DID Document metadata.
Credo
Credo is an SDK which supports the European Architecture and Reference Framework (ARF) standards as well as AnonCreds with full cheqd support for DIDs.
Veramo
The Veramo SDK Plugin supports JSON, JSON-LD credentials as well as cheqd Credential Payments in an SDK.
Walt.id Community Stack
Walt.id Community Stack is an SDK that supports the European Architecture and Reference Framework (ARF) standards for identity, with full cheqd support.
DID Registrar
Simple setup for building cheqd DIDs into existing applications using REST APIs, building into the Universal Registrar.
cheqd Cosmos CLI
Cosmos CLI which directly communicates with the cheqd network. This should only be used for testing environments.
This endpoint updates a DID Document. As an input, it can take JUST the sections/parameters that need to be updated in the DID Document (in this scenario, it fetches the current DID Document and applies the updated section). Alternatively, it take the fully-assembled DID Document with updated sections as well as unchanged sections.
/did/update
DID identifier to be updated.
did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0
Service section of the DID Document.
Verification Method section of the DID Document.
Authentication section of the DID Document.
List of key references (publicKeys) which will be used for signing the message. The should be in hexadecimal format and placed in the wallet of current user.
This input field contains either a complete DID document, or an incremental change (diff) to a DID document. See Universal DID Registrar specification.
{"@context":["https://www.w3.org/ns/did/v1"],"id":"did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0","controller":["did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0"],"verificationMethod":[{"id":"did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1","type":"Ed25519VerificationKey2018","controller":"did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0","publicKeyBase58":"z6MkkVbyHJLLjdjU5B62DaJ4mkdMdUkttf9UqySSkA9bVTeZ"}],"authentication":["did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1"],"service":[{"id":"did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#service-1","type":"LinkedDomains","serviceEndpoint":["https://example.com"]}]}
This endpoint deactivates a DID Document by taking the DID identifier as input. Must be called and signed by the DID owner.
/did/deactivate/{did}
DID identifier to deactivate.
List of key references (publicKeys) which will be used for signing the message. The should be in hexadecimal format and placed in the wallet of current user.
Set up your account
Set up your account with cheqd Studio and get your API key to start using the APIs.
This endpoint creates a DID and associated DID Document. As input, it can take the DID Document parameters via a form, or the fully-assembled DID Document itself.
/did/create
Network to create the DID on (testnet or mainnet)
testnet
, mainnet
Algorithm to use for generating the method-specific ID. The two styles supported are UUIDs and Indy-style Base58. See cheqd DID method documentation for more details.
uuid
, base58btc
Type of verification method to use for the DID. See DID Core specification for more details. Only the types listed below are supported.
Ed25519VerificationKey2018
, JsonWebKey2020
, Ed25519VerificationKey2020
It's a list of special objects which are designed to build the actual service. It's almost the same as in DID Core specification, but instead of id
it utilises idFragment
field for making the right id
for each service. !!! WARN. Cause swagger-ui does not handle x-ww-form based arrays correctly, please frame all your services in brackets while using swagger UI. !!!
[{"idFragment":"service-1","type":"LinkedDomains","serviceEndpoint":["https://example.com"]}]
The unique identifier in hexadecimal public key format used in the verification method to create the DID.
["https://www.w3.org/ns/did/v1"]
This endpoint creates a DID and associated DID Document. As input, it can take the DID Document parameters via a form, or the fully-assembled DID Document itself.
/did/create
Network to create the DID on (testnet or mainnet)
testnet
, mainnet
Algorithm to use for generating the method-specific ID. The two styles supported are UUIDs and Indy-style Base58. See cheqd DID method documentation for more details.
uuid
, base58btc
Type of verification method to use for the DID. See DID Core specification for more details. Only the types listed below are supported.
Ed25519VerificationKey2018
, JsonWebKey2020
, Ed25519VerificationKey2020
It's a list of special objects which are designed to build the actual service. It's almost the same as in DID Core specification, but instead of id
it utilises idFragment
field for making the right id
for each service. !!! WARN. Cause swagger-ui does not handle x-ww-form based arrays correctly, please frame all your services in brackets while using swagger UI. !!!
[{"idFragment":"service-1","type":"LinkedDomains","serviceEndpoint":["https://example.com"]}]
The unique identifier in hexadecimal public key format used in the verification method to create the DID.
["https://www.w3.org/ns/did/v1"]
This endpoint returns the list of DIDs controlled by the account.
/did/list
Create DIDs and identity keys using cheqd's DID Method (did:cheqd)
A Decentralized Identifier "DID" is a globally unique identifier that does not require a centralized registration authority because it is registered with distributed ledger technology or other form of decentralized network.
Learn about DIDs If you want to .
There are many different ways to create DIDs on cheqd, with options for easy integration (e.g. cheqd Studio) and more bespoke integrations (e.g. Credo and Veramo). Below are a list of options for creating cheqd DIDs.
The easiest way to start creating DIDs is with our product cheqd Studio, allowing users to build and create did:cheqd
DIDs using REST APIs.
DIDs created using cheqd Studio use the did:cheqd
DID Method. This is fully defined below, as well as the associated ledger-write fees:
Resolve a DID Document by DID identifier. Also supports DID Resolution Queries as defined in the W3C DID Resolution specification.
/did/search/{did}
DID identifier to resolve.
did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0
Return only metadata of DID Document instead of actual DID Document.
Unique UUID version identifier of DID Document. Allows for fetching a specific version of the DID Document. See cheqd DID Method Specification for more details.
3ccde6ba-6ba5-56f2-9f4f-8825561a9860
Returns the closest version of the DID Document at or before specified time. See DID Resolution handling for did:cheqd
for more details.
1970-01-01T00:00:00Z
This directive transforms the Verification Method key format from the version in the DID Document to the specified format chosen below.
Ed25519VerificationKey2018
, Ed25519VerificationKey2020
, JsonWebKey2020
Query DID Document for a specific Service Endpoint by Service ID (e.g., service-1
in did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#service-1
). This will typically redirect to the Service Endpoint based on DID Resolution specification algorithm.
service-1
Relative reference is a query fragment appended to the Service Endpoint URL. Must be used along with the service
query property above. See DID Resolution specification algorithm for more details.
/path/to/file
Issuers may want to create identity keypairs for multiple reasons, such as for signing payloads or for creating did:key
DIDs.
There is also an option to fetch an identity keypair by inputting a Key ID (kid) as a request format.
cheqd Studio currently supports two types of subject
DIDs:
did:key
did:vda
Simple setup for building cheqd DIDs into existing applications using REST APIs, building into the .
With the former, you can follow the to create a subject DID based on a generated keypair.
With the latter, you can setup your subject DID on your . Using cheqd Studio, you will be able to send credentials to your Verida wallet and use it to store and securely back them up.
This endpoint creates an identity key pair associated with the user's account for custodian-mode clients.
/key/create
Key type of the identity key pair to create.
Ed25519
, Secp256k1
This endpoint fetches an identity key pair's details for a given key ID. Only the user account associated with the custodian-mode client can fetch the key pair.
/key/read/{kid}
Key ID of the identity key pair to fetch.
DID Write Pricing
Click here to understand the price of DIDs and other resources on cheqd, compared to other identity networks.