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
- TLS works. We assume the TLS PKI is sound enough for HTTPS to bind the site identity, just as the rest of the web does.
- DNS resolution is observable. An attacker on-path may see DNS queries; with DNSSEC (recommended) they cannot forge responses.
- The site's private key is held by the site operator. Key compromise is treated as an incident, not a normal state.
- Clocks are loosely synchronized. ±300 s tolerance on signature timestamps.
- Storage is honest. The site's database honors the
UNIQUEconstraints that anchor idempotency. (Server-side DBs do; eventual-consistency stores do not — see /atp-semantics.)
2. Adversary model
| Adversary | Defense | Notes |
|---|---|---|
| Passive network observer | DEFENDED | TLS confidentiality; signatures don't leak secrets. |
| Active MITM on HTTPS | DEFENDED | Inherits TLS PKI protection. |
| Off-path forger (no key, no zone control) | DEFENDED | Ed25519 forgery is infeasible. |
| Replay of captured signed request | DEFENDED | ±300 s window + single-use nonce burn. |
| Duplicate / out-of-order client retries | DEFENDED | Idempotency key + DB UNIQUE. |
| Cross-origin agent confusion | DEFENDED | Receipts and intents bind site; agents reject mismatches. |
| DNS spoofing without DNSSEC | PARTIAL | Fallback verification via /.well-known/wab.json over HTTPS; DNSSEC strongly recommended. |
| Compromised site private key | PARTIAL | Detected via key-rotation log + receipt audit. Mitigated by rotation. See /key-rotation. |
| Sybil at the Reality Anchor / trust-graph layer | PARTIAL | Weighted quorum and admission cost discussed in §4. Current production weighting favors long-lived, DNSSEC-validated origins. |
| Malicious site operator (declares lies) | OUT OF SCOPE | WAB authenticates the origin; the policy layer (Ring 4, user consent, agent rules) must judge intent. |
| Compromised user device | OUT OF SCOPE | Standard endpoint security applies; we limit blast radius via short-lived tokens. |
| Quantum adversary against Ed25519 | OUT OF SCOPE | Post-quantum migration tracked at schema_version; not a 2026 threat. |
| Network-layer DoS | OUT OF SCOPE | Belongs 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:
- Origin age — first-seen timestamp of the DNS TXT record, validated by an independent passive observer.
- DNSSEC-validated chain — origins with a validated chain receive higher weight.
- Receipt history — origins with a non-trivial history of verifiable ATP receipts (Ed25519, no compensations beyond the ambient rate) accumulate weight.
- Independent attestors — when more than one attestor is online, no single attestor's vote can exceed 1/3 of the weight (BFT-style cap).
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.
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:
- Detect — the site operator publishes a signed
revoked_keyslist in their next manifest version. Agents that already cached the old key learn of the revocation on next discovery refresh (TTL ≤ 1 h recommended). - Rotate — a new keypair is generated; the new public key replaces
public_keyand is co-signed by the old key during a grace window. - Revoke — old key is added to a published revocation list at
/.well-known/wab-revocations.jsonand to the Ring 4 trust graph. - 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
- Spam intents — bounded by per-user rate limit (default 60/min) and per-IP request budget at the edge.
- Pre-emptive nonce burns — an attacker submits a malformed intent to burn the nonce. The intent table records the burn but does not advance state; the legitimate retry simply uses a fresh nonce.
- Receipt griefing — an attacker calls the public
verifyendpoint with garbage. The endpoint is constant-time and rate-limited; verification is stateless and cheap. - Compensation race — two parties try to compensate the same transaction. The first wins; the second receives
409 already_compensated. The audit log records both attempts.
6. Document history
- 2026-05-25 — Initial publication. Reflects v3.17.x protocol.
Related: /security · /responsible-disclosure · /key-rotation · /atp-semantics