WAB Threat Model

An explicit, falsifiable description of the adversaries WAB defends against, the ones it only partially mitigates, and the ones it does not address at all. Companion to /security.

1. Trust assumptions

2. Adversary model

AdversaryDefenseNotes
Passive network observerDEFENDEDTLS confidentiality; signatures don't leak secrets.
Active MITM on HTTPSDEFENDEDInherits TLS PKI protection.
Off-path forger (no key, no zone control)DEFENDEDEd25519 forgery is infeasible.
Replay of captured signed requestDEFENDED±300 s window + single-use nonce burn.
Duplicate / out-of-order client retriesDEFENDEDIdempotency key + DB UNIQUE.
Cross-origin agent confusionDEFENDEDReceipts and intents bind site; agents reject mismatches.
DNS spoofing without DNSSECPARTIALFallback verification via /.well-known/wab.json over HTTPS; DNSSEC strongly recommended.
Compromised site private keyPARTIALDetected via key-rotation log + receipt audit. Mitigated by rotation. See /key-rotation.
Sybil at the Reality Anchor / trust-graph layerPARTIALWeighted quorum and admission cost discussed in §4. Current production weighting favors long-lived, DNSSEC-validated origins.
Malicious site operator (declares lies)OUT OF SCOPEWAB authenticates the origin; the policy layer (Ring 4, user consent, agent rules) must judge intent.
Compromised user deviceOUT OF SCOPEStandard endpoint security applies; we limit blast radius via short-lived tokens.
Quantum adversary against Ed25519OUT OF SCOPEPost-quantum migration tracked at schema_version; not a 2026 threat.
Network-layer DoSOUT OF SCOPEBelongs to your edge (CDN/WAF).

3. Sybil & reputation considerations

The Ring 4 trust graph is a signal, not a vote. To resist Sybil inflation we currently weight contributions by:

Admission has a real, non-zero cost: a registered domain, a functioning DNS zone, and a published key. This makes farm-scale Sybils economically unattractive, but it is not free — high-value scenarios should layer additional policy at the agent.

Honest status: the Reality Anchor weighting algorithm is implemented and live, but the formal quorum proof and a public dashboard of attestor diversity are still in progress. We will publish the algorithm before promoting it from signal to gate.

4. Site-key compromise scenarios

If a site's Ed25519 private key leaks, an attacker can issue valid-looking manifests and receipts. WAB responds in four layers:

  1. Detect — the site operator publishes a signed revoked_keys list in their next manifest version. Agents that already cached the old key learn of the revocation on next discovery refresh (TTL ≤ 1 h recommended).
  2. Rotate — a new keypair is generated; the new public key replaces public_key and is co-signed by the old key during a grace window.
  3. Revoke — old key is added to a published revocation list at /.well-known/wab-revocations.json and to the Ring 4 trust graph.
  4. Reconcile — receipts signed by the revoked key remain mathematically valid but are marked distrusted in the trust graph from the revocation timestamp forward. Downstream parties decide whether to accept them.

Full procedure: /key-rotation.

5. Abuse scenarios at the application layer

6. Document history

Related: /security · /responsible-disclosure · /key-rotation · /atp-semantics