Signal freshness is the degree to which authorization context reflects current conditions when a policy decision is evaluated. A correct policy can still make an unsafe decision when it relies on a device posture, employment status, risk score, or account state that has changed since the signal was collected. Freshness is therefore a design choice alongside which signals are used and how they reach the policy decision point (PDP). section 12.0 section 12.4
Freshness is not simply “use live data.” It balances assurance against latency, system load, availability, and dependency on upstream systems. A low-risk collaboration feature may accept context embedded in an hour-long token; a production deployment decision may need live operational data and short-lived device posture information. section 12.0 section 12.4
Authorization signals commonly fall on a freshness spectrum:
- Embedded signals are fixed when a token is issued and remain usable until token expiry. They add no runtime lookup latency but can become stale quickly. section 12.4.1
- Cached signals are fetched periodically and reused for a defined interval. They reduce lookup cost while accepting bounded staleness for facts that change infrequently. section 12.4.1
- Live signals are retrieved for each decision. They provide the most current value but add latency and reliance on the upstream source. section 12.4.1
Hybrid freshness for deployment access
A deployment tool can keep employee identity and device trust in a token while querying on-call status in real time. This keeps most context local but prevents an engineer who has gone off call from retaining deployment access beyond a short cache interval or an invalidation update. Different attributes need different lifetimes: employment data may change rarely, while device posture can change hourly. section 12.3.3 section 12.4.4
Caching policy must account for dependencies, not just a single time-to-live (TTL). A combined entity can contain attributes with sharply different rates of change, so tracking each signal’s source, TTL, and validation method helps prevent a slowly changing attribute from masking a fast-changing security condition. section 12.4.4
Revocation reduces the time during which stale context can authorize access. Event-driven delivery and cache invalidation can shorten exposure windows when a signal changes. For verifiable credentials, expiration provides a predictable freshness limit, but revocation status is needed when employment, accreditation, or certification changes unexpectedly despite a credential remaining cryptographically valid. section 12.8 section 16.4
Freshness also depends on trust in the signal and its status information. A credential status check may use a real-time endpoint or a signed revocation list checked locally; before relying on credential claims, the authorization engine verifies that the credential has not been revoked. This makes freshness an operational and governance concern as well as a policy concern. section 16.4 section 16.9
