A production deployment request may come from an authenticated engineer, yet still require a compliant device, current on-call status, and an approved change window. A contextual signal, also called a trust signal, is a value about the identity, resource, request, device, environment, account, or operational state that makes an authorization decision concrete. Policies use these values to decide whether access should be allowed under current conditions. section 12.0 section 12.3.1
Design authorization context along three connected dimensions:
- Choose relevant signals, such as identity and role details, device posture, account status, location, time of day, fraud score, clearance level, or on-call status. Sensitivity and risk determine how much context a decision needs. section 12.3.1
- Choose delivery: signed token claims provide speed, decision-time API queries provide freshness, and hybrid designs combine stable token context with changing operational or risk data. section 12.3.2
- Choose freshness: embedded values remain fixed until token expiry, cached values trade some staleness for performance, and live values are retrieved for each decision. section 12.4.1
Match context to decision risk
Viewing a document may need only role and ownership. A production deployment can require device trust, time of day, and on-call status. Customer collaboration can tolerate longer-lived token claims for many actions, while engineering tools need current device, on-call, and change-management data because stale values could authorize a high-risk action. section 12.3.1 section 12.7
A signal is useful only when it is trustworthy. Preserve authenticity, integrity, and confidentiality as it moves from an originating system through a Policy Information Point (PIP), Policy Decision Point (PDP), and Policy Enforcement Point (PEP). Signed tokens can be validated against trusted issuers; API retrieval commonly uses TLS and may use mutual TLS. Event streams, sidecars, and message buses can distribute rapid updates such as revocations, but require monitoring and careful deployment. section 12.5 section 12.5.1
Contextual signals support dynamic and zero-trust authorization: authentication establishes who or what made a request, while identity attributes, device posture, operational status, and environmental context influence the policy decision enforced at the resource. Normalized, governed signals help separate policy logic from individual applications and make decisions more consistent and auditable. section 15.2 section 12.8
Table 12.1 ACME’s trust signals across different contexts. Each system occupies a different point within the three-dimensional choice space—balancing accuracy, latency, and complexity—to align with its risk profile. The Customer Collaboration platform prioritizes performance with token-based context; employees use a hybrid approach combining stable and short-lived signals; and the engineering tools depend on high-assurance, real-time data to avoid stale or unauthorized deployments. The freshness times in the table are typical and may vary depending on actual needs.
| Context |
Key signals |
Delivery method |
Freshness model |
|---|---|---|---|
| Customers on the Customer Collaboration platform |
Customer ID, role, account status, fraud score |
OAuth token (ID plus role); customer authn system API query for status |
Token = 1 hour; account/fraud data refreshed every few hours |
| Employees on the Customer Collaboration platform |
Employee identity, HR status, department, Finance limit, device posture |
Internal API calls (HR, Finance); signed device-trust token from posture client |
HR/Finance cached daily; device-trust token expires in 15 minutes |
| Engineers using deployment tools |
Employee identity, on-call status, device posture, change ticket approval, CI/CD build verification |
Internal identity service; real-time PagerDuty API; signed device-posture token; CI/CD and change-management APIs |
On-call and posture data ≤ 5 minutes; others cached daily |
Compare how customer, employee, and engineering contexts combine different signals, delivery methods, and freshness targets for their risk profiles. section 12.7
