Threat Model Review
This document reviews the specification against the threat model (context/threat-model.md) to verify that each identified threat is addressed by the protocol design.
Review Summary
| ID | Threat | Addressed | Mechanism | Gaps |
|---|---|---|---|---|
| T1 | Signal spoofing | Yes | Central authority issues all signals; Ed25519 signatures (ADR-007) | None |
| T2 | Authority impersonation | Yes | Known authority domain; TLS + JWKS public key verification | None |
| T3 | Signal manipulation in transit | Yes | Application-layer Ed25519 signatures | None |
| T4 | Replay attacks | Yes | expires field; agents reject expired responses (per spec) | None |
| T5 | Review manipulation | Partial | Authority-side aggregation from verified sources; source_count field | See below |
| T6 | Prompt injection via trust data | Partial | Structured JSON; typed fields; assessment fields bounded | See below |
| T7 | Denial of service | Yes | Signed cached responses remain valid within expires; implementation-defined rate limiting | None |
| T8 | Sybil attacks on agent identity | Yes | did:web ties identity to a controlled domain; authority acceptance policies | None |
| T9 | Authority corruption | Partial | Signed responses are non-repudiable; a transparency log on the roadmap would add public auditability | See below |
Detailed Review
T1: Signal Spoofing — Fully Addressed
A service provider cannot forge trust signals. Signals originate from the central trust authority and carry its Ed25519 signature. Agents verify the signature against the authority's published JWKS before processing. Validation Scenario 4 confirms that tampered responses are detected and rejected.
T2: Authority Impersonation — Fully Addressed
The protocol uses a known authority domain. Agents validate the authority through TLS certificate verification and by checking response signatures against the authority's JWKS at /.well-known/jwks.json. A fake authority cannot produce valid signatures.
The link tag (<link rel="trstd-protocol">) on a service provider's page points to the authority URL. An attacker could inject a link tag pointing to a fake authority, but the spec requires agents to validate that the endpoint domain matches a known trust authority (see architecture/discovery.md).
T3: Signal Manipulation in Transit — Fully Addressed
Application-layer signatures detect any modification after signing. This works even when responses traverse caches or proxies.
Limitation: Error responses (4xx, 5xx) are unsigned because they contain no trust data. A man-in-the-middle can forge a 404 entityNotFound to suppress a valid entity. The specification addresses this with mandatory error handling rules: agents MUST retry, prefer cached signed responses, and treat unresolved errors as "trust unknown" rather than "entity not found." See API specification — Agent Error Handling.
T4: Replay Attacks — Fully Addressed
Every response includes an expires field. The spec requires agents to reject responses past their expiration (see architecture/api.md). Validation Scenario 3 confirms that expired cached responses are not used even when the authority is unreachable.
T5: Review Manipulation — Partially Addressed
The protocol transmits reputation aggregates from the authority, which collects from verified sources. The sourceCount field lets agents assess breadth.
Remaining gap: The protocol does not specify how the authority validates review authenticity. Fake reviews submitted to legitimate review platforms would propagate through the system. This is an operational concern for the trust authority, not a protocol design issue — but the specification should acknowledge it.
Recommendation: Add a non-normative note in architecture/trust-signals.md stating that reputation signal accuracy depends on the authority's source verification practices.
T6: Prompt Injection via Trust Data — Partially Addressed
Signal types documented by the specification use structured, typed fields (strings with constrained semantics, booleans, numbers). The specification warns implementers against feeding raw data into LLM prompts. The optional assessment section introduces bounded free-text fields (reasoning, highlights) with character limits and authority-only authorship (see ADR-010, architecture/security.md).
Remaining gap: Authority-defined signal types have an open data schema (additionalProperties: true in the OpenAPI spec). A signal type with large string fields could carry an injection payload. A total payload size limit per signal (4 KB) bounds this risk.
Recommendation: Add a normative total payload size limit per signal to cap the injection surface.
T7: Denial of Service — Fully Addressed
Signed responses remain valid when cached within their expires window. Authority unavailability does not invalidate previously cached responses that have not expired. The authority MAY enforce rate limits using an implementation-defined strategy. Validation Scenario 3 covers the authority-unavailable case.
T8: Sybil Attacks — Fully Addressed
Agent identity uses did:web, which requires controlling a domain and hosting a DID Document. This is a higher bar than creating anonymous accounts. The trust authority can maintain an allowlist of accepted agent identities for additional control.
T9: Authority Corruption — Partially Addressed
Signed responses create a non-repudiable record — the authority cannot deny issuing a specific response. However, agents cannot today detect if the authority issues contradictory signals to different agents or silently revokes signals. A transparency log — a Merkle tree of all responses any party can monitor for suspicious patterns — is tracked on the roadmap. Governance mechanisms remain out of scope for the protocol.
Open Improvements
- Review source transparency: Add a non-normative note about review signal accuracy depending on authority source verification.
The protocol's current security model is sound.