# ARD Trust Manifest A Trust Manifest is the optional block of verifiable metadata attached to a catalog entry (or to the catalog's host) in the [[Agentic Resource Discovery Specification (ARD)|ARD]]. It answers the question an agent has to ask before connecting to anything: who published this, can I prove it, and what have they attested to? It sits alongside the artifact as a peer; it never wraps or changes the artifact's own format. ## What's in it - **`identity`** (required) — a globally unique cryptographic identifier for the workload: a SPIFFE ID, a DID (e.g. `did:web:acme.com`), or an HTTPS domain URI. Its domain must line up with the publisher segment of the entry's [[ARD URN Identifier|urn:air identifier]]. That alignment is the whole point: the logical name and the cryptographic identity have to agree. - **`identityType`** — `spiffe`, `did`, `https`, or `other`. - **`attestations`** — a list of claims like `SOC2-Type2`, `HIPAA-Audit`, `ISO27001`, or `publisher-identity`. Each points at a document (`uri`, `mediaType`) and can carry a `digest` hash for integrity. - **`provenance`** — where this artifact came from (`derivedFrom`, `publishedFrom`, `copiedFrom`) with source identifiers and digests. - **`signature`** — a detached JWS signature over the manifest, so the whole block can be verified. ## The trust model: declare vs verify Here's the part that's easy to get wrong. **ARD itself verifies nothing.** It gives publishers a standard way to *declare* identity and claims, and it gives registries and clients a standard way to *check* them. Trust comes from the curation of the registry and the verification done by the client, not from the protocol waving something through. Verification layers up: 1. **Transport** — HTTPS/TLS gets you a secure pipe, but not protection from a compromised host. 2. **Digests** — provenance hashes catch tampering after the fetch. 3. **Signed manifest (JWS)** — the signature is checked against the publisher's public key, resolved from their DID document, a JWKS endpoint, or a SPIFFE certificate. This closes the gap where someone swaps a whole catalog. 4. **Content-addressed distribution (OCI + Cosign)** — at the strongest level, substitution becomes structurally impossible. A client must reject a Trust Manifest whose `identity` doesn't match the entry it's attached to. No match, no trust. ## My take This is the right division of labor. A discovery protocol should not pretend to be a certificate authority. ARD's job is to make claims *checkable* (consistent fields, signatures, a domain-anchored identity that ties back to the [[ARD URN Identifier|URN]]) and then get out of the way so registries curate and clients verify. The danger is the lazy middle: publishers who fill in `identity` and skip the signature, and clients that read a 95 relevance `score` from an [[Agent Registry (ARD)|Agent Registry]] as if it meant "safe." It doesn't. Relevance and trust are different axes, and the spec is careful to keep them apart. So should everyone building on it. ## References - https://agenticresourcediscovery.org/ - https://agenticresourcediscovery.org/ai_catalog_spec/ - https://github.com/ards-project/ard-spec ## Related - [[Agentic Resource Discovery Specification (ARD)]] - [[ARD URN Identifier]] - [[AI Catalog (ai-catalog.json)]] - [[Agent Registry (ARD)]]