Offline authorisation and the revocation gap

Revocation is often drawn as an instantaneous switch. In a distributed system it is a state change that must reach every decision point that could still honour the credential. When a point is disconnected, the central authority can record the revocation but cannot make the remote endpoint know it.

The honest architecture therefore shows a propagation boundary. Until trusted reconnection or an enforceable local expiry, the endpoint is operating on an earlier authority snapshot. Calling that state revoked locally would describe an intention, not an observed control.

A short-lived lease or credential places an upper bound on how long stale authority may remain usable, provided the endpoint can enforce time and prevent rollback. The right duration is not a universal number. It follows from mission need, transaction consequence, data classification, expected disconnection and confidence in the local enforcement base.

Shorter life reduces exposure but increases the chance that legitimate work stops before communication returns. Longer life supports continuity but widens the period in which central revocation may be invisible. That is a governance trade-off, not a cryptographic defect that an algorithm name can erase.

A timestamp in a file is not self-enforcing. The endpoint needs a trustworthy way to establish that the lease has ended and a protected record of the state it has already accepted. Clock rollback, restored snapshots or copied credentials can otherwise reopen authority that policy intended to close.

Software-only enforcement may still be useful in a bounded lab or low-consequence path, but its limits should remain visible. Stronger claims depend on the target host, protected time or monotonic state, secure storage, update policy and operational ownership.

A returning endpoint should first refresh lifecycle state and revalidate its authority. Queued actions need to be reconciled against the central history, and any event that occurred inside the residual window should remain attributable to the snapshot that authorised it. Silent rewriting would destroy the very evidence needed to review the risk.

If reconnection occurs after revocation but before expiry, the refreshed state should end local authority. If the lease expired first, it should already be unusable. Both outcomes need tests because a system that only checks revocation online may accidentally treat network return as permission to renew stale state.

An offline path should name the maximum residual window, eligible operations, excluded data, endpoint assumptions, evidence obligations and the person or body authorised to accept the exposure. ‘Business continuity’ is not a sufficient risk statement; it describes the benefit while leaving the cost unnamed.

A stop condition is equally important. If trusted time is unavailable, evidence cannot be protected or reconciliation repeatedly fails, the system should know which operations cease. An offline design becomes governable when both continued operation and refusal are deliberate.