The device is under the user's control. Values produced by the application cannot all carry the same authority as trusted server data. A trust boundary makes that difference explicit.
Evaluation approach
Recheck identity, content, authorization and freshness when information crosses a boundary. An encrypted connection protects transport; it does not remove those checks.
Application example
Calculate prices and promotion rules on the server instead of copying a client-supplied price directly into an order. Use the client to display information and request operations.
Limits and considerations
A signed application can still execute faulty business logic. Verifying application identity does not establish that its business data is correct.
Why the origin of data matters
The same JSON field might contain an ordinary client assertion or a claim confirmed by a trusted verifier. Similar field names do not give them equal assurance. The server must know which values it independently verified and which it uses only as observations.
User identity, application identity and device identity are also distinct. Verifying one does not confer the authority associated with another. Asking about identity, authorization, freshness and integrity at each boundary helps expose weak links in the design.
Checks and decisions
- Classify client data
- Identify server authority
- Bind verification to the operation
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.