Related Work
Existing standards and protocols that inform the #trstd <protocol> design. For each, we note what it does, what we adopt, and where the #trstd <protocol> diverges.
Discovery Mechanisms
.well-known URIs (RFC 8615)
A convention for placing metadata at predictable paths under /.well-known/. Used by Let's Encrypt (ACME), OpenID Connect, OAuth, and others.
Current and planned: Agents currently use an HTML <link rel="trstd-protocol"> tag pointing directly to the verify endpoint. A /.well-known/trstd.json manifest is on the roadmap to give agents a predictable entry point without parsing HTML.
robots.txt
The original machine-readable file at a well-known path. Tells crawlers what they may access.
Relevance: Demonstrates that a simple file at a known location can achieve wide adoption. The robots.txt model — a static file that machines check before acting — directly informs the .well-known/trstd.json approach.
Divergence: robots.txt is advisory and unsigned. The trstd discovery file points to an authoritative verification endpoint rather than containing trust data itself.
HTML Link Tags
Link tags (<link>) declare relationships between the current document and external resources.
Adopted: The #trstd <protocol> uses <link rel="trstd-protocol"> as the discovery mechanism, pointing directly to the HTTP verify endpoint with a pre-computed entityId. This is the simplest integration path for trstd-aware agents. MCP and WebMCP discovery are on the roadmap to reach agents that do not know the protocol.
Limitation: Link tags require HTML parsing and only work for HTML documents. They are not as predictable as a well-known URI.
Identity and Authentication
Decentralized Identifiers — DIDs (W3C Recommendation)
A W3C standard for self-sovereign identifiers. A DID (e.g., did:web:agent.example.org) resolves to a DID Document containing public keys and service endpoints. No central registry required.
Adopted: Agent identity uses did:web identifiers carried as JWT headers in requests to the trust authority. Agent identification is optional per-request — authorities MUST NOT gate access on identification (see ADR-006). This ties agent identity to a domain the operator controls without requiring centralized registration.
Limitation: The DID ecosystem is still maturing. Tooling and library support varies. The did:web method relies on DNS and HTTPS — it inherits their trust model rather than providing an independent one.
JSON Web Tokens — JWTs (RFC 7519)
A compact, signed token format for claims between parties. Widely used for API authentication.
Adopted: The #trstd <protocol> uses JWTs for agent authentication headers and for signed trust responses from the authority.
OpenID Connect
An identity layer on top of OAuth 2.0. Provides authentication and identity claims via ID Tokens (JWTs).
Relevance: Demonstrates how identity claims can be structured, signed, and verified in a standard way. The #trstd <protocol>'s trust signals follow a similar pattern: structured claims, signed by an authority, verified by the consumer.
Divergence: OpenID Connect authenticates users. The #trstd <protocol> assesses the trustworthiness of services. Different problem, similar mechanics.
Structured Data
Schema.org
A vocabulary for structured data on web pages, supported by Google, Bing, Yahoo, and Yandex. Uses JSON-LD, Microdata, or RDFa to embed machine-readable descriptions of products, organizations, reviews, and more.
Relevance: Schema.org provides vocabularies for Organization, Review, Product, and AggregateRating — all relevant to trust assessment. Agents already encounter Schema.org markup when browsing websites.
Divergence: Schema.org data is self-asserted by the website owner and unsigned. It describes what a website claims about itself. The #trstd <protocol> provides independently verified signals from a trust authority. Schema.org tells you what the site says; trstd tells you what an authority has verified.
JSON-LD (W3C Recommendation)
A method for encoding Linked Data in JSON. Used by Schema.org for structured data embedding.
Relevance: JSON-LD's approach to typed, linked data influenced the trstd response format's use of structured JSON with explicit types and source references.
Divergence: The #trstd <protocol> uses plain JSON with a defined schema rather than JSON-LD. JSON-LD's flexibility (contexts, graph structures) adds parsing overhead that agents do not need for trust assessment.
Trust and Verification
Certificate Transparency (RFC 6962)
A system for publicly logging TLS certificates. Certificate Authorities must submit certificates to append-only logs. Monitors and auditors watch for misissued certificates.
On the roadmap. The #trstd <protocol>'s planned transparency log follows the Certificate Transparency model: a public, append-only ledger of trust signal responses to deter silent revocation, backdating, and authority misbehavior. The current spec relies on response signatures for integrity.
Web of Trust (PGP)
A decentralized trust model where individuals vouch for each other's public keys. Trust is transitive — if you trust Alice, and Alice trusts Bob, you have a degree of trust in Bob.
Not adopted: The #trstd <protocol> uses a central trust authority rather than transitive peer trust. Web of Trust requires participants to evaluate trust chains themselves. Agents need deterministic, pre-evaluated trust signals — not a graph to traverse. The central authority model trades decentralization for simplicity and speed.
Extended Validation (EV) Certificates
TLS certificates with verified organizational identity. The issuing CA confirms the legal entity behind the domain.
Relevance: EV certificates demonstrate that identity verification by a trusted third party adds value beyond domain control. The #trstd <protocol>'s identity verification signal serves a similar purpose but provides richer data (business details, verification date, verification scope) than a binary EV/non-EV distinction.
Limitation: EV certificates lost their browser UI distinction (the green bar). Market adoption declined. This suggests that trust indicators must be actionable and machine-consumable, not just visual — exactly what the #trstd <protocol> provides.
API Standards
OpenAPI Specification
A standard for describing HTTP APIs. Defines endpoints, parameters, request/response schemas, and authentication.
Adopted: The #trstd <protocol> publishes its verification API as an OpenAPI specification. This enables code generation, documentation, and automated testing for implementers.
Summary of Influences
| Standard | What We Adopt | What We Change |
|---|---|---|
.well-known (RFC 8615) | Pattern for predictable metadata paths | Used for JWKS today; manifest on the roadmap |
| DIDs (W3C) | Agent identity via did:web (optional per-authority) | Scope to JWT headers only |
| JWTs (RFC 7519) | Token format for auth and signatures | — |
| Schema.org | Vocabulary inspiration for signal types | Independent verification, not self-assertion |
| Certificate Transparency | Append-only transparency log model | On the roadmap for trust signals, not TLS certs |
| OpenAPI | API specification format | — |