Product Docs
Product DocsTechnical DocsLearning & GovernanceUseful Links
  • Product Docs
  • Node Docs
  • Learning Docs
  • ℹ️Getting Started
    • Product Overview
    • ➡️Get Started with cheqd Studio
      • 👉Set Up Your Account
      • 🗝️Create API Keys
      • 🪙Token Top Up
      • 🔄Advanced Configuration Options
    • ☑️Use Trust Registries for AI Agents
      • 🏗️Build an AI Agent Trust Registry
        • Setup AI Agent Trust Registry
          • Issue Verifiable Credentials to AI Agent
        • Setup and Configure MCP Server
          • Create AI Agent DID
          • Import Credential to AI Agent
          • Advanced functionality
            • Issue a Verifiable Credential
            • Verify a Credential
      • 🤝Validate AI Agent Trust Chain
  • 🟢Start using cheqd
    • 🆔Create DIDs and Identity Keys
      • Create a DID
      • Create Identity Keys
      • Create a Subject DID
      • Resolve a DID
      • Update a DID
      • Deactivate a DID
    • ✅Issue Credentials and Presentations
      • Issue a Verifiable Credential
      • Setup Verida Wallet
      • Verify a Verifiable Credential
      • Verify a Verifiable Presentation
      • Revoke a Verifiable Credential
      • Suspend or Unsuspend a Verifiable Credential
    • ♻️Charge for Verifiable Credentials
      • Understanding Credential Payments
        • Access Control Conditions
        • Privacy Considerations
      • Charge for Status List
      • Issue Credential with Encrypted Status List
      • Create Verifier Pays Issuer flow
      • Bulk Update or Rotate Encryption Keys
    • 🤝Build Trust Registries
      • Decentralized Trust Chains (DTCs)
        • Root Authorisations
        • RTAO -> TAO
        • TAO -> SubTAO
        • TAO -> Trusted Issuer (TI)
        • Referencing Trust Registry within a Verifiable Credential
      • Set up Trust Chain
        • Issue a Verifiable Accreditation
        • Verify a Verifiable Accreditation
      • Get Started with TRAIN
        • Deploy TRAIN and Anchor rTAO in DNS
        • Validate Trust Chain
    • 🎋Create Status Lists
      • Bitstring Status List
        • Create Bitstring Status List
        • Update Bitstring Status List
        • Check Bitstring Status List
        • Search Bitstring Status List
      • Token Status List
        • Create Token Status List
        • Update Token Status List
    • ↕️Create DID-Linked Resources
      • Understanding DID-Linked Resources
        • Context for developing DID-Linked Resources
        • Technical composition of DID-Linked Resources
        • Referencing DID-Linked Resources in VCs
      • Create a DID-Linked Resource
      • Search for DID-Linked Resources
  • 🛠️Integrate an SDK
    • Choosing the right SDK
    • 🍏Credo
      • Setup Credo Agent
      • Decentralized Identifiers (DIDs)
        • Create a DID
        • Update a DID
        • Deactivate a DID
      • DID-Linked Resources
        • Create a DID-Linked Resource
        • Resolve a DID-Linked Resource
        • Create an AnonCreds Schema
        • Create an AnonCreds Credential Definition
      • Verifiable Credentials and Presentations
        • AnonCreds
          • Issue a Verifiable Credential
          • Present a Verifiable Credential
        • JSON-LD
          • Issue a Verifiable Credential
          • Present a Verifiable Credential
        • SD-JWT VC
          • Issue a Verifiable Credential
          • Present a Verifiable Credential
    • 🍊ACA-Py
      • Setup ACA-Py Agent
      • Decentralized Identifiers (DIDs)
        • Create a DID
        • Update a DID
        • Deactivate a DID
      • DID-Linked Resources
        • Create AnonCreds Schema
        • Create AnonCreds Credential Definition
      • Verifiable Credentials and Presentations
        • AnonCreds
          • Issue a Verifiable Credential
          • Present a Verifiable Credential
          • Revoke a Verifiable Credential
        • JSON-LD
          • Issue a Verifiable Credential
          • Present a Verifiable Credential
    • 🍈Veramo
      • Setup Veramo CLI for cheqd
        • Troubleshooting Veramo CLI Setup
      • Decentralized Identifiers (DIDs)
        • Create a DID
        • Querying a DID
        • Update an existing DID
        • Deactivate a DID
        • Create an off-ledger holder DID
        • Managing Identity Keys
        • Troubleshooting
      • Verifiable Credentials and Presentations
        • Issue a Verifiable Credential
        • Verify a Verifiable Credential
        • Create a Verifiable Presentation
        • Verify a Verifiable Presentation
      • Credential Payments
        • Charge for Status List
        • Issue Credential with Encrypted Status List
        • Verifier pays Issuer
      • Bitstring Status List
        • Create Status List
        • Issuing a Verifiable Credential referencing Status List
      • DID-Linked Resources
        • Create a DID-Linked Resource
        • Create a new Resource version within existing Collection
    • 🫐Walt.id Community Stack
  • 🏗️Architecture
    • Architecture Decision Record (ADR) Process
    • List of ADRs
      • 🔵ADR 001: cheqd DID Method
      • 🟢ADR 002: DID-Linked Resources
      • 🟡ADR 003: DID Resolver
      • 🟠ADR 004: DID Registrar
      • 🟣ADR 005: DID Resolution & DID URL Dereferencing
  • 💫Advanced features and alternatives
    • ➡️DID Registrar
      • Setup DID Registrar
      • Create a DID
      • Create a DID-Linked Resource
    • ⬅️DID Resolver
      • Setup DID Resolver
    • ⚡AnonCreds Object Method
      • Schemas
      • Credential Definitions
      • Revocation Registry Definitions
      • Revocation Status Lists
    • 🌠Advanced Tooling
      • cheqd Cosmos CLI for identity
        • Create a DID
        • Update a DID
        • Deactivate a DID
        • Query a DID
        • Create a DID-Linked Resource
        • Update a DID-Linked Resource
      • Direct interaction with ledger code
      • VDR Tools CLI with cheqd (deprecated)
      • Demo Wallet for Identity Setup
  • ⚛️Network
    • Get started with cheqd Network
      • Identity Write Pricing
      • Comparison to Hyperledger Indy
    • ⏩Setup your Wallet
      • Setup Leap Wallet
        • Congifure cheqd Testnet for Leap
      • Setup Keplr Wallet
      • Migrate from Keplr to Leap Wallet
    • ↪️Useful Tools and APIs
      • Block Explorer
      • Testnet Faucet
      • Validator Status API
      • Cheqd x Cosmos Data APIs
      • Cosmos Airdrop Helpers
      • Cosmos Address Convertor
      • Ethereum Bridge
    • ⬆️Network Upgrades
      • 2021
        • 0.1.x
        • 0.2.x
        • 0.3.x
      • 2022
        • 0.4.x
        • 0.5.x
        • 0.6.x
      • 2023
        • 1.x
      • 2024
        • 2.x
        • 3.x
      • 2025
        • 3.1.x
        • 4.x
      • Root Cause Analysis of Outages
        • v1.x upgrade RCA
  • ⚖️Legal
    • License
    • Code of Conduct
    • Security Policy
  • 🆘Support
    • System Status
    • Discord
    • Bugs & Feature Requests
Powered by GitBook
LogoLogo

General

  • Website
  • Blog
  • Get $CHEQ

Product Docs

  • Product Docs
  • cheqd Studio
  • Creds.xyz
  • Bug/Feature Requests

Technical Docs

  • Node Docs
  • GitHub
  • Block Explorer

Learning Docs

  • Learning Docs
  • Governance Docs
  • Governance Forum
  • Governance Explorer
On this page
  • v0.5.0: Improved DID functionality [March 2022]
  • Identity Improvements
  • Tech Debt & Bug Fixes

Was this helpful?

Edit on GitHub
Export as PDF
  1. Network
  2. Network Upgrades
  3. 2022

0.5.x

Read about the major cheqd network upgrades, moving to version 0.5.x

Last updated 2 days ago

Was this helpful?

This list contains all stable releases in the v0.5.x family, and skips pre-release versions.

: Improved DID functionality [March 2022]

This new node version is intended to enhance functionality currently available on v0.4.x. The upgrade to v0.5.x will be a breaking change that introduces new routes, fixes a few technical debt issues identified and overall offers significant enhancements to the identity functionality and security of the network.

Full changelog:

Identity Improvements

Improved validation of did:cheqd identifiers

What has changed?

Our provides a unique identification number for a DID Subject. This can be thought of in a very similar way to traditional bank cards. (Note: While the example of a bank card is used here, DIDs on ledger are typically written for companies, not individuals.)

Within a bank card, different sections of the card identify different actors, such as the Network, Issuer ID and a Unique Account Number - and when put together, you have a complete card number. DIDs are similar, in the sense that different components of the DID mean different things:

In this update, cheqd has updated the way that DIDs are created and resolved to ensure that the Unique Identifier is a Base58 encoded string (either 16 or 32 characters long). This was done to keep it consistent with the

Why it is important?

Prior to the upgrade, the ledger code itself was relatively “dumb”: the responsibility of ensuring that a valid unique identifier was created, matching our DID specification, would be done client-side. While the cheqd ledger did implement a uniqueness check to ensure that no other DIDs with the same identifier existed within a namespace, it didn’t implement checks to ensure that the identifier specification was met. (This is broadly how a lot of Hyperledger Indy SDKs currently do this.)

We believe that that there will be a blend of various levels of technical complexity in client-side SDKs that interact with DIDs, so relying on only client SDKs to implement this is an unsafe method. By adding checks on the ledger itself, it allows us to ensure consistency across a wide range of client SDKs.

We are additionally exploring future iterations which would allow unique identifiers to be defined as instead of the Indy DID method technique as well.

More comprehensive cryptographic checks for DID updates

What has changed?

The cheqd DID method allows multiple controllers, verification methods, and complex relationships to be defined which brings it in-line with the DID Core specification. But this also introduces new challenges. To illustrate through an example, let’s say there is:

  1. Next, there is a request to add a new Verification Method to the DID Document.

  2. The question is: how should this DID Document be updated; who needs to sign to make this change?

Why it is important?

Prior to the upgrade, when a DID update request was made, the ledger would only ask for the existing Verification Method(s) listed in the DID Document to sign to approve the change. We have changed this to ensure that both the existing and new Verification Method keys need to sign the update request.

Improved DID Resolution metadata for updated DIDs

What has changed?

When a DID is resolved, it fetches resolution metadata in addition to the DID Document. This metadata contains entries such as when a DID was created as well as when it was most recently updated.

Prior to the upgrade, the Update metadata field would contain the same data as the Created field if the DID had never been updated. We’ve changed this to a null value instead of the same date/time, to make it easier for software to understand this scenario.

Why it is important?

If you see the Update field reads null, it means the DIDDoc has never been updated. This clears up any potential confusion and aligns the DID resolution metadata.

Implemented static validation for Verification Method keys

What has changed?

We have changed the way we validate Verification Method keys, splitting this into:

  • Static validation;

  • Dynamic validation.

The former, static validation checks, are performed before the inclusion of a transaction in the mempool; and the latter, dynamic validation checks, are performed during the transaction execution once it is included in the blockchain.

Why it is important?

Splitting these is important because now errors in Verification Method keys can be caught earlier and flagged, before any transaction enters the mempool.

Note: The mempool serves the purpose of keeping track of transactions seen by all full-nodes. Full-nodes keep a mempool cache of the last ‘mempool.cache_size’ transactions they have seen, as a first line of defence to prevent replay attacks.

Therefore, the validation improvements will allow nodes to reject invalid transactions in the early stages without including them in the chain and charging the user.

This in turn speeds up the cheqd network as incorrect transactions are not being committed and incorrect Verification Method keys are not errored out when committing a transaction to the mempool.

We’re also using other work to build similar efficiency improvements:

  • This validator package for null checks, generic DID validity checks in static validation

  • This validator package for DID namespace checks in dynamic validation.

Implemented JSON Web Key (JWK) support

What has changed?

Within the DID Core specification there are two types of key in a Verification Method:

  • JSON Web Key (JWK); and

  • Public Key Multibase.

Previously, the only format of key supported was publicKeyMultibase

Having only one of these two options limits the scalability and interoperability of the cheqd network, as the supported Verification Method keys are limited.

Therefore, we implemented JSON Web Key (JWK) support.

Why it is important?

With JWK, cheqd now supports a broader selection of Public Key encoding schemes, which is an important improvement, given our focus on interoperability and eventual cross-ledger support.

Tech Debt & Bug Fixes

Fixed date/time representation in DID Resolution

What has changed?

Previously, we were using a Cosmos format of datetime, rather than what is defined in the DID core spec. Now this has been changed to align with DID Core.

Why it is important?

This aligns our DID Document metadata with DID Core, making it more semantically interoperable and spec compliant.

DID metadata VersionId now populates a Tendermint’s tx_hash in the correct format

What has changed?

As cheqd is a chain built on the Cosmos SDK, it relies on Tendermint as its consensus mechanism.

This means that when something is written to the network, there is a Tendermint transaction hash that is created. This is specific to Cosmos chains.

Within DID Document metadata, there is a field called VersionID which, as the name suggests, denotes the specific version of the DID Document.

Previously, in this field, we were generating a hash from the transaction itself to calculate the DIDDoc version ID. We have now changed this to populate a Tendermint transaction hash.

Why it is important?

This is important because the DIDDoc versionId can now be retrieved right after the creation of the DID, with the DID now more easily searchable on a Block Explorer. Previously, we needed to create the DID, then ask it to create version ID, then update.

This update streamlines the process and makes it more efficient.

In Hyperledger Indy, the assumption was that DID would have only one and one per DID. The has evolved since then to allow for multiple controllers and more complex .

Learn more about DID’s (Decentralised Identifiers) and why they’re important on .

A DID Document with three Verification Methods listed within the section of the DID Document (“DIDDoc”)

This is important because it will prove that the controller(s) of any new Verification Method(s) have control of the relevant key(s) that the DID update is trying to achieve. This is much more secure because it achieves a level of trust that all of the Verification Method(s) listed in the DID Document can be appropriately signed for by their Controller(s). It also, importantly, follows the .

⚛️
⬆️
cheqd-node
v0.5.0
cheqd-node v0.5.0 release notes
did:cheqd Decentralized Identifier (DID) method
Hyperledger Indy DID method identifier specification.
UUIDs
Verification Method
Controller
DID Core specification
Verification Relationships
learn.cheqd.io
Verification Methods
DID Core Specification