The purpose of this document is to describe how a DID (and associated DIDDoc) can be created using .
NOTE: The guidance below is only recommended to be used for testing purposes!
Using cheqd-node Cosmos CLI for real-world production environments is not recommended, since the identity keys are passed in raw form to the CLI. This is fine in development/testing usage, but is not recommend for mainnet.
Developers are encouraged to use or look at .
Setup
Pre-requisites
Access to a . You can either get this from , or .
Understand how to use cheqd and .
Tokens to pay for identity transactions, since all ledger transactions are metered.
For testing purposes, CHEQ test tokens can be acquired from .
Mainnet CHEQ tokens can be .
For the remainder of this tutorial, it's assumed that the DID and associated DID Document is being created on testnet. These commands can easily be modified for mainnet.
Note: Keep this key safe! It is used to create the DIDDoc, and to update it in the future. Normally, you should be careful when cat-ing such keys as it reveals the private key as well.
2. Encode the identity key according to different verification methods
Encode the identity key's public key to one of the formats below according to the verificaiton method type you selected, as this will be later required in the verificationMethod section:
A unique-id should only be a 16-byte encoded base58 string (Indy-style) or a uuid.
For example, we can generate uuid using uuidgen tool:
uuidgen
b0ca0b75-ca6a-4674-a261-45f6dd0c9c77
The result for our example will be b0ca0b75-ca6a-4674-a261-45f6dd0c9c77, so let's use it as our unique-id in our DIDDoc.
4. Populate DIDDoc contents
Copy-paste the template below into your terminal into a blank file (e.g., using nano). We will add additional required information into the blank fields <xxxxx> in the next steps.
<namespace>: Can be testnet or mainnet. For this CLI, we strongly suggest using testnet.
<unique-id>: Unique identifier, created in step #3
<key-alias>: A key alias for the verification method identifier, e.g., #key1
<verification-method-type>: Verification method type slected from step #2 above
<public-key-base58>, <public-key-multibase>, <public-key-jwk>: Any one of the values from the result of step #2 above
<auth-key-alias>: Alias of authentication key. Can be a reference to an existing verification method.
<service-key>: Alias for service property. This is an optional section but useful to understand the power of DIDDocs.
<URI-to-object>: A valid URI that can act as a service endpoint.
The examples below show the variation in syntax for different verification method key types in the DIDDoc contents. Note that each key type has a slightly different output.
<identifier-of-your-DIDDoc>: Fully-qualified DID with <unique-id>
For example:
cheqd-noded query cheqd did "did:cheqd:testnet:b0ca0b75-ca6a-4674-a261-45f6dd0c9c77" --node https://rpc.cheqd.network:443
Congratulations! You've created, hopefully, the first of many DIDs on cheqd!
8. Query specific version
Since upgrading to 1.x.y version, we introduced versioning feature for DID Documents. This means that it is possible to get the previous version of a DID Document using the particular versionId of the document.
For querying particular version of the DID-Document the next command can be used:
Note that the output here is in snake_case because of how the cheqd ledger represents protobufs. This output would be in spec compliant JSON if queried using our DID resolver.
