In the standard request flow, assess preparation overhead separately from verification for each operation. The request digest supplied by the Android application must represent the business data that the server will actually process.
Evaluation approach
The application prepares a token provider and requests a result for an operation. It can bind the request digest through requestHash. The backend compares the expected content with the context in the evidence.
Application example
Hashing a payment amount, currency and recipient before agreeing on a stable representation can produce different results on the client and server.
Limits and considerations
The presence of a digest is insufficient. The server must reliably recompute it from the same fields.
What data does the request digest represent?
Generate requestHash consistently with the request content the server intends to verify. Hashing an arbitrary field does not bind critical values such as amount and recipient. The client and server must represent the same business data in the same way.
Define field order, null handling, number formatting and character encoding when designing a canonical representation. The server calculates the expected digest itself instead of trusting a client-supplied digest. Design legitimate retries separately within the business logic.
Checks and decisions
- Fix field ordering
- Handle preparation failures
- Reject a request with a different amount
Test that old evidence is rejected when the amount, recipient or context changes.
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.