Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Follow these instructions to update an existing did:cheqd
entry on cheqd ledger.
⚠️ Before you begin...
Make sure you've correctly configured the cheqd plugin's agent settings for Veramo CLI
Before updating the DID, you will need to prepare the updated DIDDoc and parameters for the transaction in an payload.json
file.
This file can be saved whereever you choose, but the location must be specified in the create DID command used in Step 2. (By default, it will be saved under the project root directory.)
kms
(default local
): Key Management System (KMS) to be used for storage.
did
: The did
that resolves to your DIDDoc
.
alias
: A human-friendly alias for the DID. Only used locally when referencing operations in Veramo CLI.
document
: Full body of the DID Document including updated sections.
versionId
: (optional) Custom versionId for the DID Document. If this is not set manually, then a UUID will be automatically generated for the DID Document version.
keys
: Keys used to sign the DIDDoc. These must match the ones specified in the DIDDoc, otherwise an error will be thrown.
fee
amount
: An array of coins, coins are represented as an object with 2 fields
denom
: ncheq (smallest denomination classification)
amount
: 25000000000 (This is 25 CHEQ by default and will not work with a different value)
gas
: Each transaction must specify the maximum amount of gas it may consume.
payer
(optional): The cheqd fee payer address
granter
(optional): The cheqd fee granter address, Provided the grantee has an allowance by the granter
Note that transaction fees are paid by the cheqd account set in the
agent.yml
configuration file, setup here. Each of cheqd's on-ledger identity transactions has a fixed fee, the pricing for cheqd DIDs and DID-Linked Resources can be found here. If your account has insufficient balance the transaction will fail.
Use the command below to construct and broadcast update transaction.
So, let's try to update service
section of our DIDDoc
. Then, your payload.json
file will look like this.
Note, that we are updating a service
section of in our DIDDoc
.
After you have updated the payload.json
file, run the command below to update the did
:
If you would like to fetch the updated DIDDoc body following the successful DID update result, execute the resolve
command as outlined here. You can check if service
section of DIDDoc
has been updated.
DID update operations can be complicated, especially when changing or updating keys, using multiple keys etc. Understand the design of the cheqd DID method and Verification Relationships in the W3C DID Core specification to understand the logic that is applied in these scenarios.
Learn about DIDs If you want to learn about what DIDs are, please go over to our learning site here.
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 learn about what DIDs are, please go over to our learning site here.
Below are a list of alternatives for creating cheqd DIDs.
t
Create DID
Create an Issuer DID using the did:cheqd DID method over REST API.
Create Subject DID
Create a Subject DID using the did:key or did:vda DID methods.
Resolve DID
Resolve a DID to retrieve the associated DID Document.
cheqd Studio
Our API product enables users to use cheqd's functionality with minimal complexity and easily integrate APIs into existing apps.
DID Registrar
Simple setup for building cheqd DIDs into existing applications using REST APIs, building into the Universal Registrar.
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.
Walt.id SSI Kit
Walt.id SSI Kit is an SDK that supports the European Architecture and Reference Framework (ARF) standards for identity, with full cheqd support.
cheqd Cosmos CLI
Cosmos CLI which directly communicates with the cheqd network. This should only be used for testing environments.
Follow these instructions to update an existing did:cheqd
entry on cheqd ledger.
⚠️ Before you begin...
Make sure you've correctly configured the cheqd plugin's agent settings for Veramo CLI
Construct your payload.json
file like this:
Where importantly:
denom
: ncheq (smallest denomination classification)
amount
: 10000000000 (This is 10 CHEQ by default and will not work with a different value)
Then try running the command below to deactivate the did
:
If you would like to fetch the deactivated DIDDoc, execute the resolve
command as outlined here. You can check if didDocumentMetadata
has the deactivated
flag set to true.
This guide provides common errors and potential fixes for them if you encountered errors when .
When you try to generate keys
along with DIDDoc
template using command below
If you encounter an error below
Unexpected token v in JSON at position 1
Create a .json
file (e.g. name it something like identity-keys-on-the-fly-with-did-docs.json
in same working directory level).
Copy and paste the content from below into your newly created .json
file. You can choose from any of the inputs and arguments below:
For example:
Then, instead of passing it as argument, we'll pass it as a file. Use command below to do it.
The above command will output something like this (i.e. a template DID DOC with the keys)
Then you can go back to your payload.json
file (if you didn't have one you can simply create one manually, and paste content below as template) which should be something like this at first.
Then you're going to update keys
and document
section of it (payload.json
) with keys
and didDoc
you generated in above step.
After populating keys
and document
section. Your payload.json
file should look something like this:
Assuming you have enough ncheq
tokens inside your wallet, you can now run the command below to create your DID.
If the above cmd
resulted something like this:
Account does not exist on chain. Send some tokens there before trying to query sequence.
This means you don't have enough tokens in your wallet.
After successfully creating your DID, you should see something like this:
Notice, controllerKeyId
is now the publicKeyHex
you generated the firstly. i.e did is know associated to you via publickKeyHex
or you're the controller of this the DID you created. 😄
You can go to cheqd's to get your account some test tokens.
This tutorial offers step-by-step guidance on how to create a subject DID to be used for a holder that will receive a Verifiable Credentials.
⚠️ Before you begin...
Make sure you've correctly configured the cheqd plugin's agent settings for Veramo CLI
We chose to use did:key
for the holder because the did:key
specification has a lot synergy with cheqd did method, did:cheqd
.
Using did:key
also keeps holder DIDs off-ledger. This is very important for the privacy and data protection of the holder. If holder DIDs and DIDDocs were stored on-ledger, this could constitute a risk where data written within the DIDDoc could not be removed in line with a holder's right to be forgotten.
It is also easily managable by a client agent as a full ledger backup for the writing of a DID / DID Doc is not required, thereby making it easily reproducable in a client environment.
Creating a subject did:key
DID can be achieved through both the Veramo CLI, or directly through an application that has been setup to read and write to the cheqd ledger, using the Veramo SDK for cheqd.
This off-ledger DID, of type did:key
, is used for the recipient of the Verifiable Credential and Verifiable Presentation using:
did:key
provider and KMSSelect did:key
as the provider when prompted as well as a key management system (KMS) to use (default is local
).
The agent.yml
file used for the Veramo SDK for cheqd has a preloaded local key management system which is bootstrapped along with the CLI.
The KMS is stored in a local SQLite database.
This is the nickname for your DID, which will be managed by Veramo KMS. Providing a memorable alias will help reference this for future uses, e.g., Alice off ledger DID
.
Once you have entered this, you will receive a response in a table, e.g:
did:key
Alice off ledger DID
did:key:z6MkjxdqDUWoudesywsGYbzGozUeVYiYVArdoqPcMV6m6MG4
If you got the table above, your off-ledger did:key
has been created
Follow these instructions to:
Generate identity keys on-the-fly WITH a draft DIDDoc
Generate standalone identity public/private keypairs
Convert identity key pairs generated using Veramo agent to other key encoding formats
⚠️ Before you begin...
Make sure you've correctly configured the cheqd plugin's agent settings for Veramo CLI
Instead of creating identity keys standalone, you can generate them along with a DIDDoc template. This makes it far easier to handle different inputs and arguments, such as generating DID Docs with different key types.
You can use the following command in your CLI to create your DIDDoc and associated identity keys:
You can pass the payload of the inputs and arguments as a file rather than inline using:
You can reuse this example file:
Within this command, you are able to choose from the following inputs below to produce different types of DIDDocs:
Once you have submitted the command above, you should receive a DID Document draft template, including a set of identity keys, including your chosen inputs and arguments. You can find an example of this output below:
After running the above command, if you see an unexpected error, follow our DID Operations Troubleshooting Guide to fix it. A common error is:
You can generate identity keys standalone in a plug-and-play format for future use in create DID or update DID transactions.
If you want to use identity keys outside of Veramo CLI, you can convert keys from one format to another.
For example, if you would like to convert from hex
to base64
, you can use the following generic approach:
This works with other encoding conversion libraries (i.e. multiformats
).
Follow these instructions to create a new DID and publish the associated DID Document on cheqd ledger.
⚠️ Before you begin...
Make sure you've correctly configured the cheqd plugin's agent settings for Veramo CLI
The first step is generating a template for your DID Document, including a new DID and associated public/private key pair. This process also aligns with method 1 in the key management guide.
It is important to note that this step does not create your DID on ledger, but it generates your identity keys as a draft DID Document for you to use in the on-ledger transaction in Step 3.
You can use the following command in your CLI to create your DIDDoc and associated identity keys:
You can pass the payload of the inputs and arguments as a file rather than inline using:
You can reuse this example file:
Within this command, you are able to choose from the following inputs below to produce different types of DIDDocs:
Once you have submitted the command above, you should receive a DID Document draft template, including a set of identity keys, including your chosen inputs and arguments. You can find an example of this output below:
You can then use this template to populate your payload.json
file in Step 2.
After running the above command, if you see an unexpected error, follow our DID Operations Troubleshooting Guide to fix it. A common error is:
Once you have created a template for your DIDDoc and generated your keys, and before creating a DID on-ledger, you will need to prepare the payload.json
file. This file can be saved where ever you choose, but the location must be specified in the create DID command used in Step 3. (By default, it will be saved under the project root directory.)
You should copy and paste the output of Step 1 as an initial starting template for your payload.json
file.
payload.json
filesThe below examples show the variation in syntax for different verification method key types in the DIDDoc payload file itself. Note that each key type has a slightly different output.
kms
(default local
): Key Management System (KMS) to be used for storage.
alias
: A human-friendly alias for the DID. Only used locally when referencing operations in Veramo CLI.
document
: Full body of the DID Document
versionId
: (optional): Custom versionId for the DID Document. If this is not set manually, then a UUID will be automatically generated for the DID Document version.
keys
: Keys used to sign the DIDDoc. These must match the ones specified in the DIDDoc, otherwise an error will be thrown.
fee
amount
: An array of coins, coins are represented as an object with 2 fields
denom
: ncheq (smallest denomination classification)
amount
: 50000000000 (This is 50 CHEQ by default and will not work with a different value)
gas
: Each transaction must specify the maximum amount of gas it may consume.
payer
(optional): The cheqd fee payer address
granter
(optional): The cheqd fee granter address, Provided the grantee has an allowance by the granter
Note that transaction fees are paid by the cheqd account set in the
agent.yml
configuration file, setup here. Each of cheqd's on-ledger identity transactions has a fixed fee, the pricing for cheqd DIDs and DID-Linked Resources can be found here. If your account has insufficient balance the transaction will fail.
If you do not specify the --argsFile
, you can also paste a JSON inline argument object by using the --argsJSON
flag followed by the JSON payload.
If your transaction is successful, you'll receive a success message along with the transaction details. You can query your DID using the instructions here to see the representation of your DID Document on-ledger.
If you are using testnet, you can top-up your testnet balance using our testnet faucet.
You can also configure your Keplr wallet to support cheqd testnet using the instructions here.
If you are using mainnet, you can purchase CHEQ tokens here.
Check out our troubleshooting guide for DID Operations to see common errors and fixes.
Follow these instructions to query a DID from cheqd ledger.
⚠️ Before you begin...
Make sure you've correctly for Veramo CLI
Use veramo did resolve <did>
to resolve a DID. For example:
TIp: If you have followed along the process of creating a did. You can put your did instead.
The output should look like the following:
DID queries are passed and handled using . You can also check out the API endpoints exposed by the DID Resolver to understand how this can be fetched/consumed outside Veramo CLI.