Skip to main content

Protocol Overview

The #trstd <protocol> enables AI agents to assess the trustworthiness of websites and services through machine-readable, independently verified trust signals.

Problem​

Agents act on behalf of users — browsing, comparing, purchasing. Unlike humans, agents lack visual and contextual cues for trust (brand recognition, professional design, word of mouth). Without a structured trust layer, agents cannot answer: "Is it safe to buy here?"

Solution​

A central trust authority verifies claims about service providers and exposes those signals through an HTTP API. Agents discover the API endpoint on the service provider's website, query the authority, and receive signed, structured trust data.

Verification Flow​

Step 1: The agent visits a service provider's website or API.

Step 2: The agent scans the HTML <head> for a <link rel="trstd-protocol"> tag. The tag contains the trust authority's verify endpoint URL with the page's entityId already in the URL path (/v1/entities/{entityId}/trust-signals).

Step 3: The agent validates the endpoint domain against its authority allowlist, appends ?url=...&context=... to the href, and makes an HTTP GET. Agent identification is optional per-request — agents MAY present a did:web JWT, and authorities MUST NOT gate access on it.

Step 4: The trust authority validates the URL against the entity scope, then returns a signed JSON response containing all trust signals — identity verification, review aggregates, compliance status, and more. Each signal includes its type, verification date, and type-specific data.

Step 6 (agent-side): The agent evaluates the signals against its policies and decides whether to proceed with the transaction.

Design Principles​

Authority-verified, not self-asserted. Trust signals come from a central authority that independently verifies claims. Service providers cannot fabricate signals.

Structured and typed. Responses use JSON with a defined schema. Signal types are enumerated and extensible. Signal data fields use typed values, not free text. The optional assessment section (ADR-010) introduces bounded natural-language fields for LLM consumption, with character limits and authority-only authorship to mitigate prompt injection risk.

Signed and verifiable. All responses are cryptographically signed. Agents verify the authority's Ed25519 signature before processing.

One call, full picture. A single HTTP call to /v1/entities/{entityId}/trust-signals returns all trust signals for an entity. Agents do not need to aggregate data from multiple endpoints.

Facts, not scores. The signals array provides verified facts with verification dates. The protocol does not compute a composite trust score. Agents decide what level of trust meets their user's needs. An optional assessment section allows the authority to provide a contextual recommendation derived from the signals — clearly labeled as the authority's interpretation, not a protocol-defined score.

Key Decisions​

DecisionChoiceADR
Discovery<link rel="trstd-protocol"> direct HTTPADR-001
EndpointSingle /v1/entities/{entityId}/trust-signals endpointADR-002
Trust authorityCentral registryADR-005
Signal taxonomyOpen taxonomy with reference typesADR-003
Agent identityDID-based (did:web JWT via TSAI protocol), optional per-authorityADR-006
Response formatSignals with verification metadataADR-004
Assessment layerOptional authority interpretation for LLM agentsADR-010
SecuritySigned responsesADR-007
VersioningURL path versioning (/v1/)ADR-008
Post-transaction feedbackOut of scope—

For planned future work — manifest discovery, MCP/WebMCP, transparency log, federation — see the roadmap.

What the Protocol Does Not Do​

  • Score trust. The signals array provides facts. The optional assessment is the authority's interpretation, not a protocol-defined trust score. Agents make the final decision.
  • Replace reviews. The protocol aggregates and verifies reputation data from external sources. It does not host reviews.
  • Guarantee outcomes. A high-trust signal means the authority has verified certain claims. It does not guarantee the transaction will succeed.
  • Authenticate users. The protocol assesses services, not the humans behind agents.

Specification Documents​

The normative specification lives in architecture/: