--- title: "Witnessed evidence, mapped to verifiable-credential formats - Trooth" description: "How Trooth's signed evidence lines up with the verifiable-credential and attestation formats a verifier already knows: the Trust Ledger Token as a portable credential, the audit-chain block as an attestation, and the notary semantics that keep Trooth honest about what it does and does not vouch for." canonical_url: "https://trooth.co/docs/verifiable-evidence" markdown_url: "https://trooth.co/docs/verifiable-evidence.md" generated_from: "the rendered page, converted to Markdown when this was requested" agent_index: "https://trooth.co/llms.txt" --- # Verifiable evidence Trooth publishes two signed objects that a buyer or an agent usually meets, and three others with narrower uses. This page says, for each one, exactly which bytes are signed, what they are about, which key signs them and how to check them without Trooth. The profile itself, its facts and a company's declarations are not signed by anyone. ## Every signed object, exactly | Object | Signed bytes | About | Key | Status and replay | Check it yourself | | --- | --- | --- | --- | --- | --- | | Witness statement, `trooth.witness-statement.v1` | The `payload` string itself, UTF-8, as served. Do not parse and re-serialize before checking. | One reading of one domain's public surface: each check's id, category, kind and outcome, and the counts. Not the profile or its facts. | `key_id`, listed at api.trooth.co/public/keys with its purpose and lifecycle times | No revocation list. Freshness is the `read_at` inside it, which Trooth asserts when it signs; apply the key policy published with the keys. | Ed25519 over the payload bytes; the recipe is in the [trooth-signatures](https://github.com/troothllc/trooth-signatures) repository. | | Trust Ledger Token, `tlt2` | Two signatures: the issuing company's over the token payload, and Trooth's over the signing event. Trooth's signing input does not contain the claim bytes. | The company's claims, signed by the company; Trooth's signature records that the company signed at that time. | The company's key, and Trooth's trust-ledger key | Expiry inside the token; revocation reported by the verify endpoint. | `GET api.trooth.co/v1/trust-ledger/verify/`, or the MCP tool trooth_verify. | | Signed sign-off export | The record in RFC 8785 canonical JavaScript Object Notation (JSON), one line, exactly the file's bytes; the signature travels in a sidecar. | One buyer's recorded decision about a vendor. Not a backup of an account. | The export key at `/api/verify/export-keys` | No revocation list; the record carries its own date. | The openssl command below. | | Directory receipt, `receipt_signature` | Not published. The exact bytes it covers are not served, so it cannot be checked independently today. | A published directory listing. | `authority_key_id` | Not applicable | Not possible yet. Use the witness statement. | | Audit-chain block | Internal, hash-linked records of reads of connected systems. | A company's connected-system readings. | The trust-ledger key | Hash-linked; a break shows tampering. | Not published to the public. | **The crosswalk below is conceptual.** Trooth issues no W3C Verifiable Credential, and none of these objects is a conforming one. The table maps credential vocabulary onto the nearest Trooth field so a team that thinks in credentials can place each object; it is not an interoperability claim. ## Two objects, two roles Trooth publishes two signed objects that behave like objects your systems may already consume, beside the witness statement above. ### Trust Ledger Token A portable, signed receipt a company can hand to a buyer or an agent. It behaves like a verifiable credential: a subject, an issuer, a set of claims, and a proof that re-verifies offline. Trooth co-signs it as a notary, witnessing the signing event rather than the claims. ### Audit-chain block An internal, hash-linked record of a witnessed read, signed by Trooth's attestation key. It behaves like an attestation: a statement that a specific observation was produced by Trooth at a specific time, replayable end to end. ## The crosswalk Verifiable-credential vocabulary on the left, the Trooth field that plays that role on the right. | Verifiable credential | Trooth | | --- | --- | | Credential subject | The company the profile is about, by domain or Trooth slug. | | Issuer | Trooth signs the witnessing event with its runtime attestation key. The customer signs the declared payload with a key held on their side. | | Claims | The declared state at issuance: audit-root hash, applicable frameworks, and classification. Trooth records these byte-for-byte; it does not warrant they are true. | | Proof | Two Ed25519 signatures in the Trust Ledger Token (tlt2): the customer's over the payload, and Trooth's over the witnessing event. Both re-verify independently. | | Issuance and expiry | The signed wall-clock timestamp and the token's expiry. An expired token needs re-issuing, which is not a failure of trust. | | Revocation | A revocation record keyed by the token id. The public verify endpoint reports a revoked token as revoked. | | Anchoring | None. Trooth does not record evidence with any third-party time service. The signing time inside the signature is Trooth's own statement, and anyone can check the signature against Trooth's published public key. | ## What the signature means The mapping is honest about scope. A notary stamps the act of signing; a notary does not vouch for the truthfulness of the document. Trooth's outer signature records that the customer's signature existed at the witnessed timestamp. Its signing input does not contain the claim bytes, so it does not bind the payload; the company's own signature does. It says nothing about whether the declared state is true. A verifier assesses the underlying claims independently, exactly as it would for any credential whose issuer is a notary rather than an auditor. ### Signed exports from the buyer workspace A buyer can download any sign-off as a signed record. The file is the record in RFC 8785 canonical JSON (a machine-readable format), one line, exactly the bytes Trooth signed; the Ed25519 signature and the key id travel in a sidecar beside it, never inside it. The public key is published at `/api/verify/export-keys`, and after two steps the sidecar lists (save that key's public_key_pem as trooth-export-key.pem, and base64-decode the sidecar's Signature line into export.sig), the check is one command that needs nothing from Trooth beyond that key: ``` openssl pkeyutl -verify -pubin -inkey trooth-export-key.pem -rawin \ -in trooth-signoff--.json -sigfile export.sig ``` A valid signature proves these bytes and this signer. It does not prove the decision recorded in them was right, that the vendor is safe, or that any statement in the record is true. Take the key from Trooth's site rather than from the sidecar: one source should not supply both the document and the key it is checked against. See also the [Trust Protocol](https://trooth.co/docs/trust-protocol) and [the agent pattern](https://trooth.co/docs/agents). ## Structured data ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://trooth.co/#org", "name": "Trooth", "legalName": "Trooth, LLC", "alternateName": [ "Trooth, LLC", "Trooth Network", "trooth.co" ], "url": "https://trooth.co", "logo": { "@type": "ImageObject", "@id": "https://trooth.co/#logo", "url": "https://trooth.co/brand/trooth-mark_black-on-white_1024.png", "contentUrl": "https://trooth.co/brand/trooth-mark_black-on-white_1024.png", "width": 1024, "height": 1024, "caption": "Trooth" }, "image": { "@id": "https://trooth.co/#logo" }, "description": "Trooth is an infrastructure and cybersecurity company providing Machine-Readable Trust. The Trooth Network keeps one current, evidence-backed Machine-Readable Trust Profile per company, rechecked on a schedule and signed so it can be replayed.", "foundingDate": "2025-12-16", "address": { "@type": "PostalAddress", "streetAddress": "777 Brickell Ave, Suite 500, PMB 1174", "addressLocality": "Miami", "addressRegion": "FL", "postalCode": "33131", "addressCountry": "US" }, "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "email": "hello@trooth.co", "url": "https://trooth.co/contact" }, "sameAs": [ "https://x.com/Troothllc", "https://github.com/troothllc", "https://www.crunchbase.com/organization/trooth", "https://www.wikidata.org/wiki/Q141292994", "https://www.youtube.com/@Troothllc", "https://www.trustpilot.com/review/trooth.co" ] }, { "@type": "WebSite", "@id": "https://trooth.co/#website", "url": "https://trooth.co", "name": "Trooth", "alternateName": "Trooth Network", "inLanguage": "en", "publisher": { "@id": "https://trooth.co/#org" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://trooth.co/network?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "ItemList", "@id": "https://trooth.co/#sitelinks", "name": "Trooth sitelinks", "itemListElement": [ { "@type": "SiteNavigationElement", "position": 1, "name": "Join Trooth now - it's free!", "url": "https://trooth.co/signup" }, { "@type": "SiteNavigationElement", "position": 2, "name": "Company, Trooth", "url": "https://trooth.co/network/company/trooth" }, { "@type": "SiteNavigationElement", "position": 3, "name": "Trooth Network", "url": "https://trooth.co/network" } ] } ] } ```