Attestation evaluates claims made by a client against an independent source of trust. Android and iOS do not use the same evidence format.
Evaluation approach
The server checks the expected application identity, transaction binding and evidence validity requirements. The result becomes an input to authorization.
Application example
In a registration flow, bind application evidence to the new-account request. Prevent its subsequent use for a different account or operation.
Limits and considerations
A request from a genuine application can still be abusive. User intent needs separate consideration.
Evidence needs freshness as well as scope
Attestation verifies particular claims within a defined protocol. A positive result for application identity does not prove that the user approved the payment recipient. Transaction binding addresses this gap.
When processing evidence, the server must check the expected application, environment, request context and time requirements. Design replay handling so evidence accepted earlier cannot authorize another operation. A separate service-unavailability policy also prevents unverified data from silently becoming trusted.
Checks and decisions
- Verify evidence on the server
- Set a freshness rule
- Check user authorization independently
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.