Evidence not tied to the correct amount, recipient and operation may be reused in another context. Bind verification to the work the server actually performs.
Evaluation approach
Represent relevant fields consistently and include them in the evidence flow. The server checks that context against its trusted data. Account for encoding and field-order differences.
Application example
Change the recipient or amount and confirm that earlier evidence is rejected. Separately ensure that network retries do not duplicate the transaction.
Limits and considerations
Trusting a client-supplied digest without checking its meaning is not transaction binding.
Keep approved content unchanged
Associate verification or user approval with specific business data. Changes to an amount, recipient or transaction identifier must not inherit approval for the original content. The server verifies the expected binding.
Define canonical representation and field scope because clients and servers may encode the same data differently. Legitimate retries can retrieve an existing result safely; new transactions must not reuse old evidence.
Checks and decisions
- Define covered fields
- Revalidate on the server
- Reject changed requests
Transaction binding connects cryptographic verification with business authorization.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.