cheqd DID Resolver Rust

ℹ️ Overview

DID methods are expected to provide standards-compliant methods of DID and DID Document ("DIDDoc") production. The cheqd DID Resolver is designed to implement the W3C DID Resolution specification for did:cheqd method in Rust.

📝 Architecture

The Architecture Decision Record for the cheqd DID Resolver describes the architecture & design decisions for this software package.

gRPC Endpoints used by DID Resolver

Our DID Resolver uses the Cosmos gRPC endpoint from cheqd-node to fetch data. Typically, this would be running on port 9090 on a cheqd-node instance.

You can either use public gRPC endpoints for the cheqd network (such as the default ones mentioned above), or point it to your own cheqd-node instance by enabling gRPC in the app.toml configuration file on a node:

[grpc]

# Enable defines if the gRPC server should be enabled.
enable = true

# Address defines the gRPC server address to bind to.
address = "0.0.0.0:9090"

Note: If you're pointing a DID Resolver to your own node instance, by default cheqd-node instance gRPC endpoints are not served up with a TLS certificate. This means the useTls property would need to be set to false, unless you're otherwise using a load balancer that provides TLS connections to the gRPC port.

This crate contains a resolver for DIDs of the did:cheqd method. The implementation resolves DIDs via gRPC network requests to the configured nodes. Default nodes for cheqd's mainnet & testnet can be used, or custom nodes can be opt-in by supplying a different gRPC URL configuration.

This crate uses gRPC types and clients generated using tonic. The generated rust code is checked-in to this repository for monitoring, see here. These generated rust files are checked-in alongside the V2 cheqd proto files & dependencies. which are sourced from cheqd's Buf registry.

Since the generated code & proto files are not relatively large nor overwhelming in content, they are checked-in rather than pulled and/or generated at build time. The benefit is that the contents of the files can be monitored with each update, making supply-chain attacks obvious. It also reduces the build time complexity for consumers - such as reducing requirements for any 3rd party build tools to be installed (protobuf). The drawback is that it introduces some more manual maintainence. The crate exports the DIDCheqd type which implements the [ssi_dids_core::DIDMethod] and [ssi_dids_core::resolution::DIDMethodResolver] traits. This crate is uses cheqd network's GRPC

Example

The example below is intentionally minimal and self-contained so it can be executed as a doc-test (no network calls, no async runtime). It verifies the public associated constant and basic construction of the type. This keeps cargo test --doc and tools like cargo-rdme reliable.

use did_resolver_cheqd::DIDCheqd;
use ssi_dids_core::DIDMethod;
// Confirm the API constant and that we can construct the value
assert_eq!(DIDCheqd::DID_METHOD_NAME, "cheqd");
let _ = DIDCheqd::default();
let _ = DIDCheqd::new(None);
let _ = DIDCheqd::new(Some(DidCheqdResolverConfiguration {
    networks: vec![
        NetworkConfiguration {
            grpc_url: "https://grpc.cheqd.net:443".to_string(),
            namespace: "mainnet".to_string(),
        },
    ],
}));

Library features

• Implements a DIDMethodResolver for the did:cheqd DID method.
• Exposes resolution, proto and error modules for integration.

🐞 Bug reports & 🤔 feature requests

If you notice anything not behaving how you expected, or would like to make a suggestion / request for a new feature, please create a new issue and let us k

💬 Community

Our Discord server is the primary chat channel for the open-source community, software developers, and node operators.

Please reach out to us there for discussions, help, and feedback on the project.

🙋 Find us elsewhere