Android and iOS

RASP for offline applications

Designing client, server, framework and policy layers together.

Protection architecture1 min readEditorial methods

Offline decisions rely on limited evidence. Define the duration and scope of local authority and the checks required when connectivity returns.

Evaluation approach

Specify local data access, permitted operations and reconciliation rules. Delayed evidence must not be treated as current transaction evidence.

Application example

A field worker may view documents offline while privileged changes wait for the server. Show which operations remain pending.

Limits and considerations

Offline RASP cannot know the current server-side account status.

Limits on using old evidence

Define how long the last known trust state can be used and for which operations. This carries residual risk and must not become an indefinite clean-device label. Address device-clock changes separately.

Low-risk local work may continue while high-impact operations wait. On reconnection, reassess user authority and pending records. Define what happens to offline work from a revoked session.

Checks and decisions

  • Limit offline authority
  • Define data lifetime
  • Test reconciliation

Design offline operation as a bounded mode with its own assurance limits.

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.