Everything you wanted to know about TrustDID, organized by topic. Not rocket science — promise.
TrustDID is a Canadian startup building digital trust infrastructure. We provide software that lets anyone sign, encrypt, and verify digital documents using W3C Decentralized Identifiers (DIDs) and patent-pending technology.
Think of it as a digital wax seal: when you sign a document, a small companion file (the .vrfy sidecar) proves who signed it and that it hasn't been tampered with.
No. Your website is already decentralized—you control it, not some central authority. A DID just formalizes where to publish your public keys: at a predictable URL on your own domain.
No blockchain. No tokens. No gas fees. Just a JSON file on your website.
Any file type. PDF, Word, Excel, HTML, images, CAD drawings, ZIP archives, executables—anything. TrustDID signs the SHA-256 hash of the file, not its contents, so format doesn't matter. The original document stays byte-for-byte identical.
A small JSON file that travels alongside your document. It contains the cryptographic signature, the document hash, the signer's DID reference, and a timestamp. It never modifies the original file—it's a detached companion file.
Every verification answers two independent questions.
Document authenticity — is it genuine? Cryptographic proof that not a single byte changed and that the signature matches the signer's published keys. The result is Verified, Inconsistent, Failed, or Unsigned — and it is identical for every verifier on Earth.
Trusted signer — who vouches for it? Whether a trust registry you rely on vouches for the signer. The result is Yes, No, or Unknown — and it depends on which registries you have chosen to trust.
A document can be perfectly authentic and entirely untrusted. "Document authenticity: Verified, Trusted signer: No" is a normal, honest outcome — not an error and not a low score. The math tells you it's genuine — people tell you whether to trust it.
A trust registry is a list, operated by an organization you choose to rely on — a professional association, an industry group, a government body — of the signers it vouches for. Registries are how the "Trusted signer" half of every verification gets answered.
To add a registry your verifier consults, run trustdid-setup --add-trusted-registry <registry DID>, then trustdid-check — it re-validates every configured registry (resolves its DID, probes its TRQP endpoint, and reports its public/private/token status). Manage your list with --list-trusted-registries and --remove-trusted-registry.
Don't confuse this with trustdid-setup --add-trust-registry, which publishes your own claimed affiliation in your DID document — verifiers treat that as a self-asserted claim with no trust weight by itself.
TrustDID also operates TRusty, a multi-tenant trust registry platform where organizations run their own registry at {id}.trust-registry.trustdid.ca — provisioned in seconds, public or private.
Absolutely not. TrustDID runs entirely on your computer. Signing and verification are local operations. The only network request during verification is fetching the signer's public DID from their website—a small JSON file. Your documents never leave your machine.
The signing and verification software collects nothing. It runs locally with no telemetry, no analytics, no phone-home.
If you use the trustdid.ca hosted services (email identity, cloud API), standard web server logs apply. Your documents are never stored or processed by our servers.
Signing works offline—you only need your private key, which is stored locally.
Verification needs a brief connection to fetch the signer's public DID from their website. Once fetched, the actual cryptographic verification is entirely local.
Yes. Use trustdid-keytool --rotate <profile> to rotate your keys—it archives the old keys, generates new Ed25519 + X25519 + ML-DSA-44 key pairs, and updates your DID automatically.
Old signatures remain valid—they're timestamped and reference the key ID that was active at signing time. Just like rotating passwords: old logins still happened, new ones use the new credentials.
trustdid-keytool --rotate financeOnly if you want separation of signing authority. One company, one key is perfectly fine. Or one key per department. Or one per employee. Your choice—it scales to your needs.
Generate a new key pair immediately, update your did.json, and notify your trust registry (if applicable). Signatures made with the old key before the compromise are still valid—they were legitimately signed. Signatures made after the compromise by an attacker would not match your new public key.
For high-value keys, use an HSM to prevent key extraction entirely.
Yes, by default. Every signature includes an ML-DSA-44 post-quantum signature (NIST FIPS 204 standard) alongside the Ed25519 signature. This is enabled out of the box with zero configuration. Your documents are quantum-safe from day one.
One thing to plan for: an identity on your own domain is reachable only while that domain is. Keep it registered for as long as the documents matter — we keep the keys and history, you keep the address. Identities we host are on our domain, so that part is on us.
They keep verifying — forever. Retired identities stay resolvable: your keys are marked deactivated in your DID's keyHistory, never deleted. Anyone can still verify every document you signed while your subscription was active, years later.
What stops is signing: when a license lapses, you can no longer create new signatures under that identity. Verification of everything already signed survives.
Yes. TrustDID integrates with network HSMs for enterprise deployments. Signing operations happen inside tamper-resistant hardware. Supports Crypto4A QxHSM via PKCS#11 or REST integration, enabling FIPS 140-3 certification.
DIDs follow the same hierarchy as your DNS. Divisions, departments, regional offices—each can have their own DID and signing keys. IT administrators already understand this structure.
Example: enterprise.ca/divisions/manufacturing/ gets its own DID, separate from enterprise.ca/divisions/sales/.
TrustDID signatures create an immutable audit trail: who signed what, when, with which key. This supports compliance frameworks that require document integrity and non-repudiation. Combined with HSM key storage and trust registry authorization, organizations can meet the highest compliance requirements.
Run trustdid-keytool --rotate active (or the name of the profile you want to rotate). Rotation lives in trustdid-keytool alone. TrustDID will:
1. Archive your old keys to keys/{profile}/archive/{timestamp}/
2. Generate fresh Ed25519, X25519, and ML-DSA-44 key pairs
3. Move old keys to keyHistory in your DID with a deactivated timestamp
4. Append new keys with a created timestamp
5. Re-sign your did.json
If you're in managed mode, the updated DID is pushed to the dashboard automatically. Old signatures remain verifiable because they reference the key that was active at signing time.
This means the public key on your website doesn't match the key used to sign. Common causes:
1. You regenerated keys but didn't re-deploy did.json
Fix: Upload the updated did.json to your website or push via the dashboard.
2. Your local keys are out of sync with the published DID
Fix: Run trustdid-check to identify the mismatch, then trustdid-setup --pull to sync.
3. You're signing with a profile that hasn't been published yet
Fix: Use --local flag for pre-publication signing, or deploy the profile first.
Run trustdid-check. It validates 9 phases:
✓ Config structure and version
✓ Remote DID documents are fetchable
✓ Key files exist and are loadable
✓ Public keys match private keys (.pub matches .pem)
✓ Published DID contains your key IDs
✓ DID freshness (managed mode: dashboard vs live domain)
✓ Orphan detection (unused key directories, dangling email maps)
✓ Remote orphans (profiles on server not in local config)
✓ DNSSEC records (if applicable)
Green ✓ means pass, orange ⚠ means warning, red ✗ means action needed.
Before signing, TrustDID verifies that your local signing key is published in your DID document. If you just created a new profile but haven't deployed the updated did.json yet, this check fails.
Quick fix: Use --local flag to skip the check while you're setting up: trustdid-sign document.pdf --local
Proper fix: Deploy your updated did.json to your website (or push via dashboard), then sign normally.
Run trustdid-check—it compares your local config, local DID, and the published DID on your website (and the managed copy if you use the dashboard).
If your local copy is newer (you added a profile or rotated keys): re-deploy to your website.
If the website copy is newer (someone else updated it, or dashboard pushed): run trustdid-setup --pull to sync your local copy.
If managed mode shows "DID freshness: live #active key DIFFERS from managed copy": The dashboard has a newer version than what's on your domain. Deploy from dashboard to domain.
Run trustdid-setup business --profile. You'll choose between:
Department key (e.g., finance, legal): Gets added to your org DID as #finance. Lives in the same did.json.
Personal/staff key: Gets its own DID under /public/{uuid}/did.json with an email mapping in config.json.
For headless/automated deployment on a new machine: trustdid-setup business --deploy TOKEN CUSTOMER_ID --profile-name server
From backup: TrustDID creates a compressed backup at ~/.trustdid/backup/trustdid_backup_{timestamp}.tar.gz during setup. Restore from there.
From key rotation archive: If you previously rotated keys, old keys are archived at keys/{profile}/archive/{timestamp}/.
No backup? Generate new keys with trustdid-keytool --rotate {profile} --rotation-reason key-loss-recovery, deploy the updated DID, and notify recipients. Old signatures signed with the lost key remain valid but cannot be re-created.
Prevention: Always keep an encrypted backup of your ~/.trustdid/ directory in a secure, separate location.
You recreate the profile rather than add the key. TrustDID is post-quantum by default: setup issues an ML-DSA-44 key with every profile and rotation replaces it alongside the others, so a profile without one was created before that support existed.
Remove the profile and run setup again. Patching a single key onto an older profile would leave its keys, DID document entries and history out of step with each other — a state no version of the tooling produces. Your existing signatures keep verifying through keyHistory, so nothing signed under the old keys is lost.
This means TrustDID couldn't find signed DNS records for your domain. Common causes:
Zone not signed yet: DNSSEC activation can take up to 48 hours. Test with: dig {domain} DNSKEY +dnssec
Not ready yet? Skip DNSSEC during setup and add it later with trustdid-setup --update-dnssec once your zone is signed and propagated.
Ed25519 for signing (same as SSH, Signal, age encryption). X25519 for encryption (same as WireGuard, Signal, TLS 1.3). ML-DSA-44 for post-quantum signatures (NIST FIPS 204). SHA-256 for document hashing.
A simple JSON file hosted at /.well-known/did.json on your website. It contains your public cryptographic keys—nothing secret. Verifiers fetch this file to get the public key needed to check your signatures.
Yes. The trustdid.ca Cloud Verification API provides REST endpoints for health checks, .vrfy existence probes, full signature verification, and DID resolution. Built with FastAPI, containerized with Docker, available over HTTPS.
A trusted timestamp is independent proof of when a document was signed, issued by a Time-Stamp Authority (TSA) rather than taken from the signer's own clock. The .vrfy sidecar carries these proofs in its timestampProofs array, and a verified TSA token's time — not the signer's self-asserted time — is what the verifier uses to decide which key was valid at signing time.
They defend against back-dating. Without one, someone whose key was rotated or revoked could sign a document today and claim it was signed while the key was still valid. The verifier enforces this today: a signature that relies on a revoked or historical key without a trusted timestamp fails verification with a "possible back-dating" warning.
You don't have to take our word for it. Every stamp the Time-Stamp Authority issues is written to a public, append-only transparency log (an RFC 6962 Merkle tree, the same construction Certificate Transparency uses), and the authority regularly signs the state of that log. Once a signed tree head covers N entries, nothing can be slipped in before position N: a stamp claiming an earlier time than an already-published head is provably back-dated.
trustdid-verify --audit checks a stamp against that log — that it is included under a signed head, and that the log is consistent with the last head your machine saw. The log's read endpoints are public, so you can also check with nothing but curl.
Download the free verifier, explore pricing options, or get in touch with our team.