Dock vs cheqd vs KILT: Verifiable Credential Infrastructure

Compare the issuer-to-verifier path, not three logos

A supplier has passed an organization's onboarding review. Another business unit wants to reuse that decision without collecting the same documents again. The useful credential workflow must answer who issued the statement, what it means, whether it is still valid and whether the second business unit accepts that issuer. A signature check answers only part of the problem.

Dock, cheqd and KILT already appear in FluidRWA's identity catalog. Their product and protocol layers differ. Dock's site now presents Truvera, while cheqd's documentation lists Truvera as a platform using cheqd as its primary DID method. cheqd also records a 2024 alliance and token-merger approval. A shortlist that treats all three names as unrelated, like-for-like suppliers would obscure an important dependency.

Reviewed November 6, 2026: Dock's current site, cheqd's product overview and the official KILT SDK repository. These sources establish the limited product-layer descriptions, not deployment suitability or independent compliance approval.

Dock / Truvera: define the complete business handoff

Dock's current website describes Truvera as infrastructure for reusable identity across internal systems and partners. cheqd's product overview describes Truvera as supporting credential issuance and management using cheqd. That is a reason to evaluate the application workflow and its dependencies together. Do not assume a platform agreement and a network relationship cover the same responsibilities.

For the supplier example, ask the operator to issue a synthetic credential containing the review category and expiry date. The verifier should request only the information its policy needs. Then ask what happens if the supplier's status changes after issuance. A demonstration ending at an attractive credential card has not shown the ongoing business process.

Keep the source review separate from the portable statement. A credential might say that a supplier met a particular internal policy on a specified date. It does not automatically transfer all the underlying documents or make the recipient's policy identical. Have the issuer and verifier agree the claim's meaning, permitted uses and refresh rules before technical acceptance.

Ask for the operational inventory: issuer keys, schemas, status resources, wallets, APIs, hosting and export formats. Identify which components are managed, which are customer-controlled and which depend on another service. A buyer should be able to explain how verification continues, or safely stops, during a platform outage or contract exit.

cheqd: choose the integration layer deliberately

cheqd's product documentation offers REST-based Studio, SDK integrations and lower-level ledger interaction. It lists DIDs, linked resources, status lists, trust registries and credential payments. This range gives an engineering team several entry points; it also means a bare statement that a product 'uses cheqd' tells the buyer little about what has actually been implemented.

The 2024 token-merger announcement records approval and a planned migration. Approval is a historical governance event, not evidence that every customer's migration completed. The later CHEQ information record describes the alliance and Dock platform support. Confirm your own deployment and commercial arrangement rather than extrapolating from a token announcement.

For a direct integration, assign responsibility for updating and checking status. A verifier needs a defined response when a status resource cannot be reached. 'No response' must not quietly become 'valid.' Consider cache age, permitted offline use and a review path when a status check fails. Those are buyer policies to establish, not product defaults asserted here.

If the design includes paid credential access, document which party pays for which event and what happens after an interrupted attempt. Payment for access is separate from the truth of the credential. Ask for a synthetic replay and reconciliation exercise, with the access decision and billing evidence visible as separate records. No credential-payment flow was exercised for this article.

KILT: separate the documented model from present operating evidence

KILT's official SDK repository describes a TypeScript toolkit for applications using its protocol and Claim Types, or CTYPEs. Its attestation documentation describes on-chain attestations and revocation. The protocol documentation is not a service-level commitment or a guarantee that a particular verifier handles revocation correctly.

The documentation host returned an availability error during research. We therefore do not assert current endpoint health, network capacity, supported SDK/runtime versions or staffed support arrangements. A buyer considering a new deployment should make those evidence requests explicit. An accessible repository is useful but does not establish that an integration can be operated under the buyer's requirements.

For a demonstration, ask a qualified implementer to show a credential from a trusted test issuer, a revoked version and a credential with the same structure from an unapproved issuer. The verifier should explain three different outcomes. If all it shows is a successful signature check, it has not demonstrated issuer policy or revocation handling.

Also ask what recovery changes. Replacing a holder device, rotating an issuer key and revoking a business claim are separate operations. Have the proposed supplier map each action to a responsible party and retained evidence. Do not infer that a historical statement about decentralized identity supplies a complete recovery process.

Write a credential acceptance contract before a pilot

Use synthetic identities and do not put personal records on a public ledger to make a demo more convincing. The protocol's data placement is only one part of privacy review; application logs, status lookups and correlation across verifiers also deserve attention. Qualified reviewers should determine the relevant obligations for the intended use.

Measure a bounded workflow, including exceptions and export. A successful pilot should leave the buyer with a clear account of who issued what, which verifier accepted it and which dependencies are required to check it later. It should not end with a generic interoperability claim.

Use the identity-solutions directory to frame the procurement brief. SpruceID, Privado ID and Civic Auth address adjacent identity and access patterns. This page's narrower decision is how an issued claim is managed and relied upon across organizations, including when its status changes.