ADR-005: Trust Authority Model

Status: Accepted Date: 2026-03-20

Context

Trust signals must originate from somewhere. The authority model determines who issues and validates signals, and how agents know to trust the issuer. This is the root of trust for the entire protocol.

The guidelines state "Central Trust Authorities" as a design direction.

Decision

Use a central registry model. A single trust authority (operated by or on behalf of the trstd working group) maintains the registry of verified entities and issues all trust signals.

How It Works

1. Service providers apply to the trust authority for verification
2. The authority verifies claims through independent sources (government registries, audits, review aggregation)
3. The authority issues signed trust signals for verified entities
4. Agents query the authority's /v1/entities/{entityId}/trust-signals endpoint
5. A planned transparency log (see roadmap) will record all issued signals

Authority Identity

The trust authority operates at a known domain (e.g., authority.example.org). Agents verify the authority through:

• TLS certificate for the authority's domain
• A published set of public signing keys (for response signature verification)
• The planned transparency log (see roadmap)

Service providers point agents to this authority's endpoint via the <link rel="trstd-protocol"> tag in their HTML (see discovery.md and ADR-001). A /.well-known/trstd.json manifest is roadmap material.

Onboarding

Service providers register with the authority and submit evidence for verification. The authority evaluates evidence and issues signals (ADR-004). The onboarding process is an operational concern outside the protocol specification.

Options Considered

A. Central registry (chosen). A single authority maintains the registry. Simple trust chain — agents trust one entity. Clear accountability. Single point of failure, but mitigated by signed responses with caching and the planned transparency log (see roadmap).

B. Federated authorities. Multiple independent authorities linked by mutual recognition. Resilient and competitive. Agents must discover and evaluate multiple authorities. Cross-authority trust negotiation adds protocol surface area. Premature today — federation can be added later if demand warrants it.

C. Self-asserted with attestation. Entities publish their own signals; independent attestors co-sign. Low barrier to entry. Agents must evaluate attestor credibility — this pushes trust evaluation complexity onto every agent implementation. Bootstrapping problem: who are the first credible attestors?

D. Hybrid (federated + self-assertion). Authorities verify core signals; entities self-assert supplementary ones. Flexible but adds protocol surface area for two signal categories with different trust semantics. Agents must distinguish authority-verified from self-asserted signals and reason about the difference.

Consequences

• One trust authority to implement, operate, and govern
• Agents trust one entity — verification logic is straightforward
• Service providers have one registration path
• The authority is a single point of failure for signal issuance (but not for signal verification — cached, signed responses remain valid)
• Governance of the authority (who runs it, oversight, accountability) must be defined outside the protocol
• Federation (multiple independent authorities) is out of scope today. The protocol design does not preclude adding it later (see roadmap) — the response format and signature scheme work with multiple issuers

References

• ADR-004 — Response Format
• context/threat-model.md — T9: Authority Corruption (planned transparency log mitigates; see roadmap)