Blog / BABYLON-60
A valid signature can still be a replayed authorization
A nonce, signed content and consumption state play different roles in preventing an operation from being repeated.
Authenticity and freshness are different questions
A signature that verifies may belong to a request already handled. The verifier needs to distinguish that replay from new authorization. A nonce identifies an instance of the protocol; covering it with the signature allows reuse to be detected when the necessary state is retained. RFC 9421 describes this principle for HTTP signatures. It is a design reference, not a claim that BABYLON implements that protocol or that any random value solves the whole problem.
Bind and consume before the effect
The nonce must be bound to the operation, resource and relevant conditions. Signing an identifier alone can preserve a valid signature while changing the action it supposedly authorizes. Concurrent requests also need coordination: two separate existence checks may accept the same value before either marks it as consumed. An atomic reservation or state transition needs an enforceable uniqueness rule, and the policy must define what happens when authorization expires or recovery becomes necessary.
An interruption leaves an outcome question
If a process dies after producing an effect but before recording its outcome, retrying can duplicate that effect. The protocol needs a representation of the unknown outcome and reconciliation against the observed resource. Persisting a reservation also requires defined storage and synchronization guarantees. SQLite documents differences across configurations and environments. A process-death test does not by itself demonstrate resistance to power loss; that conclusion requires a different experiment and an explicit account of its assumptions.