Replay Protection & Consistency
This page defines nonce storage, replay detection, and consistency requirements required to satisfy INV-3.
Spec Drift Warning
Changes to implementation that violate invariant mappings invalidate compliance with v1.0. Implementations MUST preserve invariant-to-component, invariant-to-artifact, and invariant-to-verification-step mapping.
Compliance Assertion
- • Satisfies INV-3 by requiring nonce-based replay detection with strong consistency.
Non-Compliance Results In
- • Eventual consistency replay prevention is non-compliant.
- • Nonce store unavailability causes denial, not execution.
Nonce Contract
Invariant Mapping: INV-3
- • Each request MUST contain a nonce unique within the configured replay window.
- • Nonce uniqueness MUST be enforced per identity and action scope.
- • Replay detection MUST occur before execution.
Consistency Requirement
Invariant Mapping: INV-3
Replay prevention under distributed conditions REQUIRES strong consistency. Eventual consistency is non-compliant.
- • The nonce store MUST provide linearizable or equivalently strong write visibility for replay checks.
- • If strong consistency is unavailable, Gate SHALL deny execution.
- • Deployments using eventual consistency for replay detection SHALL be classified as non-compliant.
Replay Detection Outcomes
Invariant Mapping: INV-3
- • If nonce exists within replay window, Gate MUST deny with a replay decision code.
- • If nonce store is unavailable, Gate MUST deny rather than execute.
- • If nonce write cannot be confirmed, Gate MUST deny rather than assume success.
Compliance Evidence
- • Storage design stating consistency model.
- • Test proving replay request is denied.
- • Test proving nonce store outage causes denial.
Verification Linkage
INV-3
Artifact: request-001.json
Check: Nonce present and bound to signed request
Verification step: verify.sh: INV-3
INV-3
Artifact: verification walkthrough
Check: Replay attempt is denied
Verification step: Adversarial scenario 2