Press enter or click to view image in full size
Authorization is commonly modeled as a binary decision: allow or deny. That model is incomplete for workflows where authorization depends on additional evidence, approval, or state transition.
A third outcome is needed according to Google’s Beyond Zero architecture: challenge.
A useful analogy is the DMV queue. You get in line, get a number, and grab a seat — your application is suspended pending completion of another step. It has not been approved, but it has not been rejected either. The system retains enough context to resume processing once the required condition is satisfied.
Authorization challenges work the same way.
A policy decision point may determine that a request is potentially authorized but currently lacks sufficient evidence. The response can identify a required action: perform phishing-resistant authentication, obtain managerial approval, present an additional credential, attest device posture, confirm a transaction, or satisfy another policy-defined condition.
This is materially different from deny. Deny terminates the request. Challenge creates a continuation point.
That distinction becomes increasingly important in agentic and distributed systems. For example, a deployment pipeline may be authorized to promote software to production only after a fresh human operator authentication. Or a background process doing analysis may have noticed something fishy about the tokens you’re presenting, and the frequency of denied authorization requests you’ve been racking up.
In these cases, returning false loses important policy context.
A richer authorization interface should therefore support at least three outcomes:
ALLOW — sufficient evidence exists. DENY — policy prohibits the action. CHALLENGE — authorization may proceed after specified conditions are satisfied.
Authorization is not always a verdict. Sometimes it is a session.