Skip to main content

Glossary

Canonical definitions for terms used throughout the #trstd <protocol> specification. When a term appears in normative or non-normative documents, its meaning matches the definition here.

Normative language follows RFC 2119: MUST, SHOULD, MAY indicate requirement levels.

Agent. Software that acts on behalf of a user — browsing, comparing, transacting. Agents discover the verify endpoint, query it, verify the response signature, and evaluate the resulting signals. An agent may be programmatic (rule-based) or LLM-based. Agents MAY present a did:web JWT as optional identification.

Agent identification. The optional presentation of a did:web JWT by an agent in the Authorization: Bearer header of a verify request. Authorities MUST NOT gate access on identification — requests without an Authorization header MUST be served. Authorities MAY use a presented identity for logging, rate-limiting, or response tailoring; these behaviors are implementation-defined. Defined in the Verification API specification and ADR-006.

Assessment. The authority's interpretation of its own signals, scoped to the agent's context. Contains a machine-readable action (proceed / caution / decline), optional reasoning, and highlights. The assessment is opinion. Signals are evidence. Agents MAY ignore the assessment and evaluate signals directly. Defined in the Verification API specification.

Authority. See Trust authority.

Entity. A company, person, or organization whose trustworthiness the trust authority attests to. Each entity has an opaque entityId issued by the trust authority and embedded in the link tag's href. A service provider with regional storefronts or separate services may have multiple entities, each with its own link tag on the relevant pages. Defined in the Discovery specification.

Context. An optional query parameter on /v1/entities/{entityId}/trust-signals that communicates the agent's intent: purchase, inquiry, or high-value. The authority uses it to tailor the optional assessment. Omitting it means no assessment or a generic one.

Custom signal. A signal whose type is not one of the five reference types. The CustomSignal schema in the OpenAPI spec accepts any authority-defined type with freeform data. Agents MUST NOT fail on custom signal types. LLM-based agents MAY interpret them from field names and values. See ADR-013.

Discovery. The mechanism by which an agent locates the trust authority's verify endpoint on a service provider's site. Agents scan HTML for a <link rel="trstd-protocol"> tag. Additional discovery mechanisms (manifest, MCP, WebMCP) are tracked on the roadmap. Defined in the Discovery specification.

did:web. A decentralized identifier method where the agent hosts a DID Document at its domain. The DID Document contains the agent's public key. Used for optional agent identification via JWT. Resolution and verification follow the TSAI protocol.

Envelope. The standard JSON structure every signal uses: type, verifiedAt, and data. The envelope fields are universal; the data field is type-specific. Defined in the Trust Signals specification.

Link tag. An HTML <link rel="trstd-protocol"> element in the page's <head>. Points to the trust authority's verify endpoint with the page's entityId already in the URL path (/v1/entities/{entityId}/trust-signals). The discovery mechanism defined by the current spec. Agents extract the href, append ?url=...&context=..., and make a single HTTP GET.

Reference type. One of five signal types documented by the specification: identity, reputation, compliance, recourse, contact. These illustrate common trust signals across domains. Authorities that represent the same concept SHOULD use the reference type name for interoperability. Authorities are not required to implement any reference type. See ADR-003.

Recourse. A reference signal type representing availability and type of recourse mechanisms — dispute resolution, complaints, appeals. Defined in the Trust Signals specification.

Reputation. A reference signal type representing aggregated reputation data from verified sources — reviews, ratings, accreditation scores. Defined in the Trust Signals specification.

Service provider. The website or agentic service being assessed. The service provider embeds the link tag in its HTML so agents can find the verify endpoint. The service provider is the subject of trust signals — not the author.

Signal. A verified fact returned by the trust authority. Each signal carries a type, a verifiedAt timestamp, and type-specific data. Signals are structured, typed, and signed by the authority. An array of signals forms the factual core of the verify response. Also referred to as trust signal in prose. Defined in the Trust Signals specification.

Signal type. A string identifying the category of a signal (e.g., identity, reputation, compliance). The authority defines which types it supports. Any string is a valid type value. The specification documents five reference types with schemas; all other types use the custom signal pattern.

Trust authority. The organization that independently verifies claims about service providers and issues trust signals. Operates the verify endpoint, signs every response with Ed25519, and is accountable for the accuracy of its signals. Also referred to as authority for brevity.

TSAI protocol. Trust Signals for Agent Interactions — an external specification defining did:web JWT mechanics, DID resolution, and agent identity certification. Referenced by the #trstd <protocol> for optional agent identification. See github.com/awslabs/tsai-protocol.

Verify / Verification. The process of checking a service provider's trustworthiness via the /v1/entities/{entityId}/trust-signals endpoint. The trust authority validates the request, assembles signals, optionally generates an assessment, signs the response, and returns it. "Verified" has two distinct uses: a signal's verifiedAt records when the authority last confirmed the underlying fact; an entity's status: verified means the authority actively vouches for it.

References​