Most authorization systems still treat denial as the end of the interaction.

1

{ "decision": false }

That model worked reasonably well in closed-world systems. Resources were known ahead of time. Applications were pre-integrated. Trust relationships were static. Permissions were provisioned before execution. Workflows were predictable enough that a denial usually meant the request was simply over.

Modern systems increasingly do not work that way.

Agents discover tools dynamically. Sub-agents delegate work downstream. Workflows cross trust boundaries. Resources appear at runtime. Missions evolve after they start. A request that is not authorized right now may still be legitimate if the right governance event occurs.

In that environment, a deny is often not a full stop. It is the beginning of an escalation process.

A support agent acting on behalf of an engineer may be authorized to investigate a tenant’s billing issue, then discover that the cause sits in a restricted payment-provider log outside its current mandate. Reauthenticating the engineer does not answer the real question. The question is whether this mission should expand to include that tenant, that log, that operation, and that time window. A requestable denial lets the PDP pause the workflow, bind the denial to the original evaluation, obtain a scoped governance decision, and reevaluate before access continues.

That is the missing primitive: not an approval flow, but a requestable denial.

The missing protocol move is a standardized way for a PDP to say: deny, but escalate.

That realization is what led me to start working on draft-mcguinness-authzen-access-request, an extension profile to the OpenID AuthZEN Authorization API for representing requestable denials, submitting access requests, and reevaluating authorization after a governance workflow completes.

But the more I worked on it, the more I realized this is not really about “access requests.” It is about something larger: authorization escalation interoperability.

Open-World Systems Break Static Authorization

Traditional authorization systems assume the authority envelope can be determined upfront: which resources will be accessed, which operations will occur, which delegation paths will exist, and which trust domains will participate.

That assumption breaks down quickly once agents enter the picture.

As discussed in OAuth for Open-World Ecosystems, modern agents increasingly discover APIs dynamically, interact with previously unknown systems, expand workflows during execution, delegate tasks downstream, and cross organizational trust boundaries. An agent may begin with a valid authorization scope and still encounter new runtime conditions: a newly discovered mailbox, a downstream SaaS API, a stronger operation, a higher-risk dataset, a new tenant boundary, or a delegated execution path.

The system now needs to answer a much harder question than “Is this token valid?”

It must answer “Should authority continue under these newly discovered runtime conditions?”

That is not authentication. That is runtime governance.

The Missing Layer Between Denial and Governance

Most authorization systems today have a structural gap. They can allow access, deny access, and sometimes return obligations or advice. What they lack is a standard way to say:

“Access is currently denied, but governance escalation is available.”

That missing layer becomes important when authorization is no longer a single synchronous yes-or-no event. Agents, delegated execution, runtime discovery, mission expansion, and continuous governance all need a way to pause, ask for additional authority, and later return to the policy decision point with evidence that the governance event occurred.

Today, that escalation is usually proprietary: custom approval APIs, ticketing integrations, internal workflow systems, ad hoc polling mechanisms, and vendor-specific governance models. Every platform invents its own approach, and the result is fragmented governance interoperability.

The AARM Approval Service frames where an agent runtime pauses: high-risk or ambiguous actions should stop for human review with full action context, identity chain, and semantic drift attached. A requestable denial frames the other side of the same boundary: how the policy layer says escalation is available, how the denial is bound to the original evaluation, and how the result returns for reevaluation.

AARM describes the runtime pause. This draft describes the authorization handoff.

What the Draft Actually Does

The goal of draft-mcguinness-authzen-access-request is not to standardize workflow engines or approval systems. It standardizes the interoperability layer around authorization escalation.

Conceptually, the draft introduces a transition from a bare denial:

1

{ "decision": false }

to a requestable denial:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "decision": false,
  "context": {
    "evaluation_id": "eval_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1",
    "reason": "approval_required",
    "access_request": {
      "endpoint": "https://pdp.example.com/access/v1/requests",
      "template": "manager_approval",
      "expires_in": 600,
      "request_context": "eyJhbGciOiJFUzI1NiIsImtpZCI6InBkcC0xIn0..."
    }
  }
}

That distinction is subtle but important. The authorization system is no longer returning only “No.” It is returning “No, but governance escalation is available.”

Mechanically, the flow is straightforward. The PEP submits a request to the advertised endpoint, echoing the denial-binding material so the request can be tied back to the original evaluation. The Access Request Service returns a Task Handle that the PEP polls until the task reaches a terminal state. On approval, the result carries an approval reference. The PEP then issues a new AuthZEN evaluation with context.approval set to that reference. The PDP reevaluates against current policy, current subject state, and current risk, and only then issues an allow.

The base profile defines exactly one completion mode: reevaluate. The PDP remains authoritative end to end. An approval is not an access grant. It is an input that current policy can choose to honor or reject.

That changes denial from a terminal state into a governable lifecycle transition without changing what a denial means.

This Is Not Workflow Standardization

One of the most important constraints of the draft is what it intentionally does not standardize. The draft does not define workflow engines, BPM orchestration, approver routing, entitlement provisioning, governance policy languages, UI semantics, or human interaction models. Those remain implementation-specific.

What the draft standardizes is narrower:

• the shape of a requestable denial in an AuthZEN decision response
• how an access request is submitted, with denial binding and idempotency
• the Task Handle, lifecycle states, and polling semantics
• terminal-state completion semantics, including reevaluation against current policy

That separation matters. An enterprise may implement approvals using ServiceNow, SailPoint, Okta workflows, a custom governance system, a risk engine, an AI supervisor, a delegated approver, or a chain of policy evaluators. The interoperability problem exists independently of the workflow engine behind it.

The draft keeps catalog references outside the form schema so the schema remains a pure description of data shape. It also does not define a UI rendering vocabulary or an agent protocol surface. The handoff is the surface area. Everything else stays local.

Why CIBA Is Not the Solution

Whenever asynchronous approval flows come up, someone eventually asks, “Why not just use CIBA?”

At first glance, CIBA appears close. Asynchronous interaction. Delayed completion. Polling semantics. Out-of-band approval. But CIBA solves a fundamentally different problem.

CIBA is asynchronous authentication and consent for OAuth grant issuance. The successful terminal state is a token. The user proves they are present and consenting, and the authorization server issues a credential.

Authorization escalation governance is different. The modern problem is often not “authenticate the user again.” The harder problem is “should authority continue under newly discovered runtime conditions?”

An agent may already possess valid tokens, operate under an approved mission, remain authenticated, and maintain runtime continuity. It may still require governance escalation because authority boundaries changed, delegation paths evolved, risk posture changed, mission scope expanded, or downstream systems introduced new constraints.

The draft intentionally avoids coupling approval directly to grant issuance. The lifecycle is:

1. authorization denied
2. escalation initiated against the denial binding
3. governance workflow executes
4. authorization context changes
5. authorization reevaluated under current policy

That distinction preserves continuous evaluation, revocation, runtime policy, dynamic governance, and mission-bound authority. Approval alone does not create durable authority. The authorization system remains authoritative at evaluation time. That keeps the policy engine in charge of the access decision rather than the workflow engine.

CIBA still has its place. When the missing input really is fresh user authentication or consent for a grant, CIBA is the right tool. When the missing input is governance state, it is not.

Sessions Are Not Missions, and Approvals Are Not Authority

An approval answers whether a governance event occurred. A mission answers whether that event still justifies authority right now. The reevaluation step in the draft keeps those two questions separate. The approval is an input to policy. Policy decides whether the input still holds.

This is the same shape as the argument in Sessions Are Not Missions. Modern agent runtimes increasingly support durable execution: resumable sessions, background jobs, distributed orchestration, asynchronous continuation, and sub-agent execution. Runtime durability is not governance durability. A session answers where the agent can continue working. A mission answers why the agent is allowed to keep working.

An agent may remain authenticated, maintain valid sessions, and preserve runtime continuity while still requiring governance escalation because new resources were discovered, stronger operations emerged, downstream delegation occurred, trust boundaries changed, or mission scope expanded. Authentication continuity is not governance continuity. An approval signed an hour ago is not a substitute for evaluating against current state.

This is also why the Task Handle in the draft is opaque and portable. It survives PEP restart and can be passed between systems. A long-running agent that gets denied, escalates, hands work off to a sub-agent, and resumes on a different node should not need to rebuild the request from scratch. The handle is a runtime artifact for tracking the escalation. The mission, the approval, and the reevaluated decision are the governance artifacts that decide whether work continues.

Authorization Escalation as a Runtime Primitive

The deeper pattern emerging across modern systems is this: authority increasingly outlives the moment that originally justified it.

A static authorization decision made at one point in time becomes insufficient once execution continues for hours or days, resources are discovered dynamically, delegation chains evolve, risk posture changes, organizational state changes, or mission scope expands.

This is the same gap From Passports to Power of Attorney names from the credential side and Governing the Stay, Not Just the Entry names from the control-plane side. The badge is not the work order. The token is not the mandate. The session is not the mission.

A standardized escalation handoff lets each of those layers stay honest. The PDP can say “deny, but escalate” without inventing its own approval API. The mandate service (Power of Attorney series) can be the system of record for whether the mission still holds. The workflow engine can remain the system of record for how an approval was reached. The agent runtime can carry a Task Handle without becoming the source of truth for authority.

What this layer needs to be:

• A protocol surface, not a workflow language. Approval routing, escalation policy, and approver selection stay implementation-specific.
• Policy-authoritative on completion. The PDP reevaluates against current state. An approval is an input, not a verdict.
• Lifecycle-explicit. Pending, approved, denied, expired, cancelled, failed, partial. Unknown states are not approval.
• Bindable to the denial. Either a verifiable evaluation identifier or a signed request context, never a floating approval against an unbound denial.
• Portable. Handles survive runtime churn and cross process boundaries, because the agents that need this most are the ones that do not stay on one node.

None of those properties are workflow features. They are interoperability properties.

What This Is Converging Toward

The traditional model:

1

{ "decision": false }

is becoming insufficient for agents, runtime delegation, dynamic resource discovery, mission expansion, and continuous governance.

The future increasingly looks more like:

1
2
3
4
5
6
7

{
  "decision": false,
  "context": {
    "reason": "approval_required",
    "access_request": { "endpoint": "...", "template": "..." }
  }
}

followed later by a reevaluation against the resulting approval. Current policy decides whether the approval still holds.

That is the direction this work is converging toward: not “access requests” as a workflow primitive, and not “approval flows” as a vendor feature, but a standardized interoperability layer for authorization escalation, runtime governance, and mission continuity.

The protocol surface is small on purpose. The hard work of deciding who approves what, under which policy, against which mission, with which evidence, stays exactly where it belongs: not in the authorization API, not in the workflow engine, but in the layer that owns mission authority.

Denial is no longer always the end of the interaction. It is becoming a state in a governable lifecycle. The protocol needs to recognize that, and only that. The rest of the stack can then stop reinventing it.