Human Oversight Profile for Agent Principal Federation

1.1. Protocol Overview

An agent acting for Alice asks for authority that policy says Alice must approve. The client opts in to deferral, and the IdP holds the request until Alice decides.¶

Client          IdP              Alice            RAS
  |              |                 |                |
  | (1) exchange, completion_mode=deferred, DPoP K  |
  |------------->|                 |                |
  | (2) authorization_pending, deferral_code        |
  |<-------------|                 |                |
  |              | (3) approval request (agent, user,
  |              |     client, target, authority)   |
  |              |---------------->|                |
  |              |<----------------|                |
  | (4) poll with deferral_code, DPoP K             |
  |------------->|                 |                |
  | (5) ID-JAG for the approved authority, cnf K    |
  |<-------------|                 |                |
  | (6) redeem as any governed grant                |
  |-------------------------------------------------->|

1. The client sends a governed token exchange request with completion_mode=deferred and a DPoP proof (Section 4.1).¶

2. The IdP completes every issuance check except Alice's decision, records the pending request, and returns a deferred response (Section 4.2).¶

3. Alice authenticates and approves the request, or a narrower one, through a channel this document does not define (Section 4.3).¶

4. The client polls with the deferral code, proving the same key.¶

5. The IdP re-checks the request and issues the governed grant the request would have produced, for the approved authority and bound to the same key (Section 4.4).¶

6. The RAS processes the grant as any governed grant under [FEDERATION].¶

1.2. Scope

This document covers governed grant issuance at the IdP, including continuation ([CONTINUATION]), governed grant redemption at the RAS, and oversight of individual actions at an API. It does not cover:¶

• approval of a task, which Mission-Bound Authorization addresses ([MISSION-APPROVAL]);¶

• multi-party approval or the provenance of an approver's authority;¶

• the approval channel or its user interface;¶

• the format or transport of notices to overseers;¶

• completion of an approved access request as a token under [AROP] at the IdP (Appendix C); or¶

• continuation from an authorization whose redemption was deferred, beyond making that authorization ineligible for it (Section 5.6, Appendix C).¶

This document defines no new token format, claim, error code, grant type, or request parameter.¶

4.1. Client Opt-In

A client that can wait for an approver includes deferred in the completion_mode parameter of its token exchange request (Section 5.1 of [DTR]). It MUST present a DPoP proof [RFC9449] on that request, whatever its client authentication method. This narrows Section 11.1 of [DTR], which lets a confidential client using private_key_jwt omit DPoP: under this document the deferral code and the grant it yields are bound to one key.¶

When policy requires human in the loop and the request does not include deferred, the IdP MUST NOT return a deferred response (Section 5.3 of [DTR]) and MUST NOT issue the grant. It rejects the request (Section 5.2 of [RFC6749]) with actor_unauthorized for delegated root issuance, and with invalid_target for self-acting root issuance and for any continuation. These are the errors [FEDERATION] assigns when approval requires a condition the selected composition cannot enforce ("Issuance Authorization" in [FEDERATION]), and, for a continuation, the code [CONTINUATION] uses for a target the chain's authorization does not permit, since a continuation uses the error codes of [ICA] ("Errors" in [CONTINUATION]); this document reuses them for an approval that the request did not let the IdP obtain. This document defines no discovery of a target's oversight mode; a client learns to opt in from configuration. A client that can wait for an approver and handle a deferred response can include deferred on every request that policy might hold, since the IdP answers synchronously when it does not defer. A refusal of such a request is not a missing opt-in, and the client does not retry it unchanged.¶

4.2. Deferring

Before returning a deferred response, the IdP MUST complete every check that [FEDERATION] requires for the request except the approver's decision: client authentication, agent resolution, the Client Association, subject validation and resolution, the Delegation or Agent Authorization, target and tenant resolution, and the client registration association. A request that fails a check is rejected as [FEDERATION] specifies and is not deferred. An approver therefore never decides on a request the IdP would refuse.¶

The IdP then records a pending governed request holding the request's governed request context, and returns the deferred response of Section 6.4 of [DTR]. The deferral code represents that pending governed request and nothing else. The IdP MUST bind it to the authenticated client and to the key of the request's DPoP proof, and MUST reject a poll or cancellation that does not prove that key (Section 11.1 of [DTR]). The IdP MUST set expires_in no greater than a configured maximum pending lifetime for the applicable policy.¶

The client does not present the subject token or the agent-resolution input again; the IdP validates them when it receives the request. The lifetime limits of [FEDERATION] still bound the grant issued at resolution: an ID-JAG does not outlive its subject credential ("Grant Issuance" in [FEDERATION]), and no grant outlives an agent-resolution input that bounds it, such as a platform JWT ("Common Grant Claims, Lifetime, and Response" in [FEDERATION]). For root issuance, the IdP MUST set expires_in so that the pending governed request ends no later than the earliest of those expirations. An approval late in the window therefore yields a shorter grant. A deployment that needs a longer window uses a subject credential that expires later, such as a refresh token.¶

4.3. Approval

The IdP MUST present a pending governed request only to approvers that policy designates for it, and MUST authenticate an approver at the strength that policy requires. For delegated access, an approver is the user or a person whom policy authorizes to decide for that user and target. For self-acting access, an approver is a person policy designates, such as the agent's accountable owner. The IdP MUST NOT accept a decision from the requesting client, the agent, or another agent.¶

The IdP MUST show the approver the governed request context: the agent, the user for delegated access, the client, the target RAS and resource, the requested authority, and, for a continuation, the continuing client. For a continuation, it MUST also show any restrictions of the chain authorization and the Continuation Association that apply to the requested target ("Restrictions" in [CONTINUATION]); an approval does not change them. Text that the client or agent supplies, such as a stated reason, MUST be shown as supplied by the requester and MUST NOT replace or restate the governed request context.¶

An approver can approve the request as shown, approve a narrower authority, or deny it. An approval MUST NOT widen the governed request context: a different agent, user, client, target, resource, or acting relationship, or broader authority, needs a new request. An approval of narrower authority yields a grant with that authority, as [RFC8693] and "Issuance Authorization" in [FEDERATION] permit, and the token response's scope reports it.¶

An approval covers only the pending governed request it was made on. The IdP MUST NOT apply it to another request, including a later request with the same governed request context.¶

An approver can condition an approval on time. The IdP enforces such a condition only on the grant it issues. It MUST NOT treat a condition on downstream access as enforced, since [FEDERATION] defines no portable deadline on authorization a RAS issues and rejects issuance whose approval requires a downstream condition the composition cannot enforce.¶

This document does not define the approval channel. [CIBA], with a binding_message that describes the request, is one way to reach the user; an access request service under [ARAP] is another. A third is the interaction_uri that a deferred or polling response can carry (Section 6.4 of [DTR]), as in the agent example of Appendix A.6 of [DTR]. The page it identifies shows the governed request context, and the approver authenticates there, after the request was created, at the strength policy requires. Reaching the URI is not that authentication, and neither is a session in a browser the agent operates, through which the agent could approve its own request (Section 10.3). Because the requesting client receives the URI, the IdP MUST NOT accept a decision made through it unless the approver authenticated there after the pending request was created; an existing session does not satisfy this. Where another server authenticates the approver, the IdP requests fresh authentication and checks that the reported authentication time is later than the request's creation. The channel rarely fits self-acting access, whose approver is seldom the client's user. A client that can present the URI to the user includes deferred_interactive with deferred (Section 5.1 of [DTR]).¶

4.4. Resolution

Before issuing a grant in response to a poll, the IdP MUST re-evaluate the request under Section 11.7 of [DTR] and, in addition, MUST confirm that:¶

• the Agent Principal is active;¶

• for root issuance, the Identity Binding and Client Association used still permit the request;¶

• the Delegation or Agent Authorization still permits the target and the approved authority;¶

• for delegated access, the user is active and resolves as before;¶

• for a continuation, neither the presented hop nor an ancestor is revoked, the chain has not ended, a Continuation Association still permits the continuing client, the target, and the approved authority, and the continuation is within the limits of Section 6.3 of [ICA] (Section 4.5); and¶

• no change applied within the IdP's freshness limit ("Issuance Authorization" in [FEDERATION]) withdraws any of these.¶

If any check fails, the IdP returns access_denied and issues no grant, as Section 11.7 of [DTR] requires. A check that cannot be completed, because state it depends on is unavailable, has not failed: the IdP MUST NOT resolve the request on that basis, and answers the poll with a pending response (Section 6.6 of [DTR]) until it can complete the check or the request expires, as [CONTINUATION] answers a continuation exchange it cannot confirm with HTTP 503 rather than ending the chain. A denial resolves to access_denied, and a pending request that outlives expires_in resolves to expired_token (Section 6.6 of [DTR]). A client cancels a pending request by revoking its deferral code (Section 8 of [DTR], [RFC7009]).¶

On success, the IdP MUST issue the governed grant that the request would have produced without deferral, with the approved authority:¶

• the same Agent Principal, acting relationship, and, for delegated access, user;¶

• the same client registration at the RAS as client_id, target, and resource;¶

• cnf.jkt equal to the thumbprint of the request's proof key; and¶

• iat and exp set when the grant issues, so that the grant's redemption window begins at resolution, within the lifetime limits of [FEDERATION] (Section 4.2).¶

The successful polling response carries the issued_token_type of the originating request (Section 6.5.2 of [DTR]). No claim in the grant indicates that an approval occurred. The IdP MAY include the txn claim [RFC8417] with an identifier of the approval, for audit correlation; a RAS or API MUST NOT treat txn as evidence of approval or as authority.¶

A client whose pending request is denied or expires MUST NOT retry it as self-acting access, under another client, or under a lower adoption profile. A later request for the same authority is a new request, and a new approval if policy requires one.¶

4.5. Continuation

A continuation exchange ([CONTINUATION]) can be deferred under this section, with the continuing client as the client. Before deferring, the IdP performs every validation step of the continuation exchange, including the Continuation Association and the limits of [ICA], and reserves the assertion as Section 5.5.7 of [ICA] requires. The pending governed request holds that reservation:¶

• Retention. The IdP MUST retain the reservation until the later of the request's end and the time Section 5.5.7 of [ICA] requires.¶

• States. Where the IdP offers idempotent retry, this document replaces one transition of Section 5.5.7.1 of [ICA] for a deferred continuation: the reservation stays RESERVED while the request is pending, rather than becoming FAILED at the assertion's exp plus the permitted clock skew. It becomes ISSUED when the onward grant issues and FAILED when the request ends otherwise, on denial, cancellation, expiry, or a failed re-check.¶

• Retries. The IdP MUST reject a second presentation of the assertion, both while the request is pending and after it ends. Recovery (Section 5.5.7.1 of [ICA]) does not apply to an onward grant issued at resolution, which only the polling response delivers (Section 6.5.2 of [DTR]).¶

A continuation exchange performs no agent resolution, so at resolution the IdP re-checks the chain and the continuing client's Continuation Association rather than an Identity Binding (Section 4.4). The continuation window is evaluated when the request is received: it bounds when a continuation can be requested, and the maximum pending lifetime bounds how long after that the onward grant can issue. A chain that ended while the request was pending resolves to access_denied; the continuing client learns of the ending from its next continuation, which fails with invalid_continuation. While the request is pending, the continuing client reports the wait to its own caller through its own interface, such as an MCP task (Section 8).¶

The limits of Section 6.3 of [ICA] count continuations that have issued, not requests, so passing them at deferral reserves no capacity. At resolution, the IdP MUST evaluate them again against the continuations issued by then, and MUST count the onward grant against them atomically with issuing it, so that continuations pending together cannot exceed a limit. A request that would exceed a limit resolves to access_denied.¶

5.1. Redemption Opt-In

A client that can wait for an approver includes deferred in the completion_mode parameter of its redemption request (Section 5.1 of [DTR]). It MUST present a DPoP proof [RFC9449] on that request, whatever its client authentication method, as for deferred issuance (Section 4.1). For a grant that contains cnf.jkt, that proof is the grant proof.¶

The RAS MUST NOT return a deferred response to a redemption request that does not include deferred or does not present a DPoP proof. It MUST NOT defer a redemption for a resource whose configuration selects mutual-TLS access tokens ("Access-Token Protection" in [FEDERATION]): Section 11.1 of [DTR] requires the token issued after a request with a DPoP proof to be bound to that proof's key, and that configuration applies mutual TLS regardless of any DPoP proof.¶

When RAS policy requires approval and the RAS does not defer, it MUST NOT issue a token. It rejects the redemption with the error it returns when its own policy refuses a redemption ("Redemption Errors" in [FEDERATION]): access_denied for an ID-JAG and invalid_target for a WAG. The response therefore does not reveal that an approval could be obtained. A client that can wait and handle a deferred response can include deferred on every redemption that RAS policy might hold, as at the IdP (Section 4.1). A RAS that defers redemptions advertises deferred_token_response_supported in its own metadata (Section 5.1 of [DTR]); the IdP's metadata says nothing about the RAS.¶

5.2. Deferring a Redemption

Before returning a deferred response, the RAS MUST complete every check that [FEDERATION] requires for the redemption except the approver's decision:¶

• Both grants: the proof and client, replay, and authority checks of "Common Grant Validation" in [FEDERATION], and the effective eligibility of the agent and, for an ID-JAG, the user, including any Local Suspension ([AGENT-LIFECYCLE]).¶

• ID-JAG: ID-JAG validation, including the grant's time claims; the actor; user resolution; correlation of the act agent; and the actor gate ("Grant Validation" in [FEDERATION]).¶

• WAG: validation of the grant, including its time claims and typ; correlation of (iss, sub) to one local agent principal; and RAS policy for the agent ("Self-Acting Redemption: WAG" in [FEDERATION]).¶

A redemption that fails a check is rejected as [FEDERATION] specifies and is not deferred. The client does not present the grant again, so its time claims are checked when the request is received; the grant's exp limits redemption, not later access ("Authorization Lifetime" in [FEDERATION]). This document thus reads the originating-grant preconditions that Section 11.7 of [DTR] re-evaluates as excluding the grant's own expiration (Appendix C). Approval can therefore come after the grant's exp. The access token then issued has iat set at resolution, and both RAS lifetime policy ("Authorization Lifetime" in [FEDERATION]) and the deadlines of Section 5.5 apply to its expiration: the approval expiry, any enforcement deadline, and the absolute authorization expiration. This departs from the recommendation of Section 4.1 of [RFC7521], which Section 5 of [WAG] repeats and [FEDERATION] keeps for direct redemption, that an access token not outlive the assertion's validity by a significant period. For a deferred redemption, those deadlines bound the access token's expiration instead, and the maximum pending lifetime bounds only how long after receipt the token can issue.¶

The RAS then accepts the grant. It MUST record the grant's (iss, jti) as accepted, whether or not the grant is bound, and MUST NOT accept the grant again for another redemption. This narrows the re-acceptance of a bound grant that "Common Grant Validation" in [FEDERATION] permits and the parallel request of Section 9.3 of [DTR]: one grant yields one outcome, and a denial cannot be bypassed by presenting the grant again. The RAS retains the record until the later of the pending redemption's end and the retention of "Time, Replay, and Key Validation" in [FEDERATION].¶

On acceptance, the RAS MUST set the absolute authorization expiration of "Optional RAS Refresh Tokens" in [FEDERATION], whether or not it later issues a refresh token, and MUST NOT issue a token for the redemption that outlives it. That section sets the expiration at issuance. Without deferral the two coincide; with deferral, a later start would extend reliance on one IdP decision by the pending time. Where the RAS already set an absolute authorization expiration for the grant, that expiration applies, and deferral does not extend it. If it has passed, the RAS does not defer: access beyond it requires a new grant, and the RAS rejects the redemption with invalid_grant.¶

The RAS records a pending governed redemption bound to the values that the checks established:¶

• the authenticated client, the Target Tenant, the resource, and the requested authority, including any authorization_details as processed;¶

• the proof key and the absolute authorization expiration;¶

• for an ID-JAG, the resolved local user, the local agent principal for act, the validated act object, and, where the RAS participates in grant-derived revocation ([AGENT-LIFECYCLE]), the revocation key;¶

• for a WAG, the local agent principal correlated from (iss, sub); and¶

• the grant as received, or a digest of it (Section 5.4).¶

The RAS MUST construct any authorization evaluation for the pending governed redemption only from these values, keeping the user, the agent, and the client distinct, as "Optional Policy Services" in [FEDERATION] requires of an API. For an ID-JAG, the agent is the issuer-qualified act; for a WAG, the agent is the subject. The client identifier never identifies the agent.¶

The RAS returns the deferred response of Section 6.4 of [DTR]. It MUST bind the deferral code to the authenticated client and the key of the request's DPoP proof, and MUST reject a poll or cancellation that does not prove that key (Section 11.1 of [DTR]). It MUST set expires_in no greater than a configured maximum pending lifetime and so that the pending governed redemption ends no later than the absolute authorization expiration. An approval after that expiration therefore finds an expired request.¶

5.3. Approval Binding

The rules of Section 4.3 apply with the RAS in place of the IdP and the values of Section 5.2 as the governed request context: approvers designated by RAS policy and authenticated at the strength it requires, never the client or an agent; the resolved values shown, with requester text shown as the requester's; approval of the request as shown or of narrower authority, never of a wider one; and time conditions enforced only on what the RAS issues.¶

The RAS MUST bind each approval to one pending governed redemption:¶

• One approval request. The RAS opens one approval request for each pending governed redemption. It MUST NOT use one approval request for two pending governed redemptions, including by treating a redemption with the same client and requested authority as a duplicate of another.¶

• Only its own approval. The RAS MUST accept an approval only for the approval request it opened for that pending governed redemption, received over an authenticated channel or verified for integrity, issuer, intended recipient, expiry, and binding. An approval for another approval request completes nothing: the pending governed redemption remains pending until its own approval, denial, or expiry.¶

• Kept unchanged. The RAS MUST keep the approval as received, including its identifier, its time values, and any state that the approval channel attaches, or a reference that retrieves it exactly. It MUST use that approval unchanged in every later evaluation. A shorter deadline that a later evaluation returns is kept separately, as an enforcement deadline, and does not modify the approval.¶

The approval expiry is the latest time at which the approval channel states the approval remains valid.¶

[ARAP] and [AROP] realize these rules. The approval request is an ARAP access request, the approval is ARAP's approval object, which ARAP carries unchanged into re-evaluation, the approval expiry is its approved_until, and completion is AROP's token issuance completion. AROP's idempotent submission compares the client and the requested authority but not the agent or the user; Section 5.4 replaces it.¶

5.4. Recovery

A pending governed redemption is recoverable until a successful token response redeems its deferral code (Section 6.5.2 of [DTR]), or until it is denied, cancelled, or expires. The RAS cannot know whether a token response reached the client; a later poll for a redeemed code fails (Section 6.5.1 of [DTR]).¶

While a pending governed redemption is recoverable, the RAS MUST return its deferral code, with the remaining expires_in, to a redemption request that presents:¶

• the accepted grant, byte for byte, matched against the stored grant or its digest;¶

• authentication of the same client and a DPoP proof of the same key, each fresh under its own replay rules;¶

• deferred in completion_mode; and¶

• the same grant_type, resource, scope, and authorization_details.¶

Recovery returns the deferred response of Section 6.4 of [DTR]. An interaction_uri that it carries, or that a later poll returns, identifies the same approval request.¶

Recovery matches the stored grant and does not validate it again, so it succeeds after the grant's exp. It is not an acceptance, opens no approval request, and changes neither the maximum pending lifetime, the absolute authorization expiration, nor the approval expiry. The RAS MUST record an acceptance and its pending governed redemption atomically, so that identical requests received together create one pending governed redemption and one approval request. Recovery issues no token, so it cannot yield a second token while a poll succeeds.¶

The RAS rejects any other presentation of an accepted grant under the replay rule of Section 5.2, with invalid_grant. This includes a presentation without deferred or with another grant type, and any presentation after the pending governed redemption ends.¶

5.5. Redemption Resolution

Only an approval accepted under Section 5.3 starts resolution; an approval for another approval request leaves the pending governed redemption pending. Before issuing a token in response to a poll, the RAS MUST re-evaluate the redemption under Section 11.7 of [DTR], with the approval kept under Section 5.3, and MUST confirm that:¶

• neither the approval's expiry nor any enforcement deadline has passed;¶

• the RAS still trusts the grant's issuer for the Target Tenant, in the grant's tenant at a multi-tenant issuer ("Canonical Identity and Tenant Boundaries" in [FEDERATION]);¶

• no applied disablement, correlation removal, local restriction, or Local Suspension affects the agent or, for an ID-JAG, the user ("Applied Disablement and Revocation" in [FEDERATION], [AGENT-LIFECYCLE]);¶

• for an ID-JAG, the user is active and resolves to the same local user, the act agent correlates to the same local agent principal, and the actor gate permits the relationship. An account-link change does not substitute another user ("User Resolution and Linking" in [FEDERATION]), and a changed agent link does not transfer the delegation ("Agent Principal Correlation" in [FEDERATION]);¶

• for a WAG, (iss, sub) correlates to the same local agent principal; and¶

• current RAS policy permits the approved authority for the client, Target Tenant, and resource.¶

If any check fails, the RAS returns access_denied and issues no token, as Section 11.7 of [DTR] requires. As at the IdP (Section 4.4), a check that cannot be completed has not failed: the RAS MUST NOT resolve the redemption on that basis, and answers the poll with a pending response until it can complete the check or the pending governed redemption expires. A denial resolves to access_denied, and a pending governed redemption that outlives expires_in resolves to expired_token (Section 6.6 of [DTR]). Grant-derived revocation of the grant reaches "all redemptions" of it ([AGENT-LIFECYCLE]), so a participating RAS ends the pending governed redemption when the event arrives, and the next poll gets access_denied. Other changes made at the IdP after receipt reach the RAS only through such signals or provisioning. The maximum pending lifetime bounds the rest, and an intervention bound (Section 6) counts it.¶

On success, the RAS MUST issue what the redemption would have produced without deferral, for the approved authority:¶

• the identities bound at receipt: for an ID-JAG, the local user as subject and act unchanged ("Actor Preservation" in [FEDERATION]); for a WAG, the local agent principal as subject and no act;¶

• an access token bound to the proof key (Section 11.1 of [DTR]), with iat set at resolution and an expiration no later than the approval expiry, any enforcement deadline, and the absolute authorization expiration; and¶

• the approved authority, which a narrower approval reduces; the response's scope reports it.¶

The successful polling response is the token response that the redemption would have returned (Section 6.5.2 of [DTR]); neither JWT grant type, jwt-bearer or jwt-dpop, defines an issued_token_type. The access token MAY carry txn for audit correlation, as a grant may (Section 4.4); an API MUST NOT treat it as evidence of approval or as authority.¶

5.6. Refresh and Continuation

A WAG redemption yields no refresh token ("Self-Acting Redemption: WAG" in [FEDERATION]), and an approval of a single use SHOULD NOT yield one. Otherwise, a refresh token for a deferred redemption follows "Optional RAS Refresh Tokens" in [FEDERATION], with the absolute authorization expiration set on acceptance (Section 5.2). The RAS MUST keep the approval with the refresh authorization. On every refresh, in addition to that section's processing, the RAS MUST evaluate the request again with the kept approval. It MUST reject the refresh with invalid_grant if the approval has expired or was revoked, cancelled, or superseded, if an enforcement deadline has passed, or if the evaluation denies. A shorter deadline that an evaluation returns becomes the enforcement deadline for every later token and for the refresh authorization. An access token issued on refresh expires no later than the approval expiry, any enforcement deadline, and the absolute authorization expiration. When the RAS rejects a refresh after authenticating the client and its proof, under this paragraph or under "Optional RAS Refresh Tokens" in [FEDERATION], it MUST end the refresh authorization, so that a later change in policy or approval does not revive it. A request that fails client authentication or proof does not end it. Access after an ended refresh authorization needs a new grant, since this one is consumed.¶

The RAS MUST NOT record an authorization from a deferred redemption as eligible for continuation ("Root Redemption at the Gateway's RAS" in [CONTINUATION]). This covers every access token issued for that authorization, including on refresh, and the deferred redemption of an onward grant as well as of a root grant. A CAI therefore refuses to attest such a token, as for any ineligible hop. Under [AROP], the approval expiry also bounds tokens obtained by exchange. Continuation exchanges the access token at the CAI and the resulting assertion at the IdP, which issues an onward grant this document cannot bound (Appendix C).¶

10.1. Approval Fatigue

An approver asked too often approves without reading. Policy that places routine requests under human in the loop trains approvers to approve. Deployments can reserve approval for requests whose authority warrants it, grant routine authority as standing authorization that a person reviews periodically, and limit how many pending requests one agent can hold. Converting an approval into standing authority is an authorization change (Section 3), not a side effect of approving.¶

A limit on pending requests does not stop sequential prompting. After a denial, a later request for the same authority is a new request (Section 4.4), so an agent, or content that misleads it, can prompt an approver again as soon as the previous request ends, until the approver accepts. This document does not define suppression of a request that matches one recently denied: doing so needs a definition of equivalent requests, a way for a policy change or an authorized reconsideration to clear it, a party that owns the limit, and the refusal it returns. Approval channels and policy can rate-limit prompts per agent and approver in the meantime.¶

10.2. Misleading Requests

An agent can phrase a request to mislead an approver. The governed request context comes from the IdP's resolution, not from the request, and the requester's own text is shown as the requester's (Section 4.3). An approver can still be misled about why the authority is needed; this document makes the request accurate, not the reason.¶

10.3. Self-Approval

An agent that could approve its own requests would remove the person the mode requires. An approver is a person designated by policy, and neither the requesting agent, its client, nor another agent can approve (Section 4.3, Section 7). How an IdP or API tells a person's decision from an automated one depends on the approval channel, which this document does not define; the channel's authentication of the approver is what makes the rule enforceable. An interaction_uri opened in a browser the agent operates is the plainest case: the page must authenticate the approver itself, after the request was created, so that a session already in that browser cannot decide (Section 4.3). A deployment that routes decisions to an automated approver is human out of the loop and records it as such (Section 3).¶

10.4. Stale Approvals

A decision can come long after the request. The IdP re-checks the agent, its bindings and associations, its authorization, the user, and the chain at resolution (Section 4.4), and the grant's lifetime starts then. The maximum pending lifetime, and for root issuance the expiration of the credentials the request presented (Section 4.2), bound how old a request can be when it is approved. At the RAS, the re-checks of Section 5.5 and an absolute authorization expiration set when the grant is accepted (Section 5.2) do the same.¶

10.5. Deferral Codes

A stolen deferral code could otherwise yield the grant after approval. The code is bound to the client and to a DPoP key (Section 4.2, Section 5.2), as Section 11.1 of [DTR] requires for clients whose profile mandates DPoP. A grant issued after a deferred issuance carries the same key, and so does a bound grant whose redemption is deferred.¶

An unbound grant does not. Whoever first redeems a stolen unbound grant, with credentials for the client it names, chooses the key the deferral code is bound to, and the approver sees the same agent, user, client, and resource as for the legitimate request. Approval therefore does not protect an unbound grant against its first redemption ("Unbound Grant Theft" in [FEDERATION]).¶

10.6. Approval Binding at the RAS

An approval matched to a request by its attributes can complete another agent's request. [ARAP]'s comparison excludes the actor, and [AROP]'s idempotent submission compares only the client and the requested authority. The RAS opens one approval request for each pending governed redemption and accepts only that request's approval (Section 5.3), so no comparison decides which redemption an approval completes.¶

10.7. Recovery

Recovery returns a deferral code only to the client that authenticates afresh and proves the deferral's key, for the grant it presented (Section 5.4). A party that holds the grant but not the key gets invalid_grant, as for any consumed grant. Recovery cannot extend a pending governed redemption or the authority that follows it.¶

10.8. Downgrade

A client that omits the opt-in, or retries a denied request another way, must not obtain the grant without the approval policy requires. Policy selects the mode, a request without the opt-in is refused rather than issued (Section 4.1, Section 5.1), and a denied or expired request is not retried as self-acting access, under another client, or under a lower profile (Section 4.4).¶

10.9. Supervised Exposure

Under supervised issuance, an agent acts before anyone reviews the grant. What it does before an overseer intervenes, and before the intervention takes effect, cannot be undone. The intervention bound (Section 6) states that window; it does not shorten it.¶

13.1. Normative References

[FEDERATION]

McGuinness, K., "OAuth 2.0 Profile for Agent Principal Federation", Work in Progress, Internet-Draft, draft-mcguinness-oauth-governed-agent-federation, <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-oauth-governed-agent-federation.html>.

[CONTINUATION]

McGuinness, K., "Identity Continuation Profile for Agent Principal Federation", Work in Progress, Internet-Draft, draft-mcguinness-oauth-governed-agent-continuation, <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-oauth-governed-agent-continuation.html>.

[DTR]

de Oliveira Niero, G. and D. Liu, "Deferred Token Response", Work in Progress, Internet-Draft, draft-ietf-oauth-deferred-token-response-01, 31 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-deferred-token-response-01>.

[ICA]

McGuinness, K. and A. Parecki, "Identity Continuation Assertion for OAuth 2.0 Token Exchange", Work in Progress, Internet-Draft, draft-mcguinness-oauth-id-continuation-assertion-02, 8 September 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-id-continuation-assertion-02>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

13.2. Informative References

[AGENT-LIFECYCLE]

McGuinness, K., "Agent Principal Lifecycle Profile for SCIM and OAuth", Work in Progress, Internet-Draft, draft-mcguinness-oauth-governed-agent-lifecycle, <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-oauth-governed-agent-lifecycle.html>.

[AIMS]

Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf-wimse-aims-01, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-aims-01>.

[ARAP]

OpenID AuthZEN Working Group, "AuthZEN Access Request and Approval Profile - Draft 1", <https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html>.

[AROP]

McGuinness, K., "AuthZEN Access Request OAuth Profile - Draft 1", <https://github.com/openid/authzen/blob/main/profiles/authzen-access-request-oauth/authzen-access-request-oauth-profile-1_0.md>.

[CIBA]

OpenID Foundation, "OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0", 1 September 2021, <https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html>.

[MCP]

Model Context Protocol, "Model Context Protocol Specification, Revision 2026-07-28", 28 July 2026, <https://modelcontextprotocol.io/specification/2026-07-28>.

[MCP-SEP-2643]

Model Context Protocol, "SEP-2643: Structured Authorization Denials", <https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2643>.

[MCP-SEP-2848]

McGuinness, K., "SEP-2848: Asynchronous Approval for Tool Calls", <https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2848>.

[MCP-TASKS]

Model Context Protocol, "Tasks Extension, Revision 2026-07-28", 28 July 2026, <https://tasks.extensions.modelcontextprotocol.io/specification/2026-07-28/tasks>.

[MISSION-APPROVAL]

McGuinness, K., "Mission Deferred Approval for OAuth 2.0", <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-approval.html>.

[OVERSIGHT-ACTS]

Ehstand, A., "Terminology for Human Oversight Acts in Automated and Agentic Systems", Work in Progress, Internet-Draft, draft-ehstand-oversight-acts-00, 26 September 2026, <https://datatracker.ietf.org/doc/html/draft-ehstand-oversight-acts-00>.

[RFC7009]

Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.

[RFC7521]

Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, May 2015, <https://www.rfc-editor.org/rfc/rfc7521>.

[RFC8417]

Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, July 2018, <https://www.rfc-editor.org/rfc/rfc8417>.

[WAG]

Carleton, P., Steele, N., Parecki, A., Schwenkschuster, A., and B. Campbell, "Workload Authorization Grant", Work in Progress, Internet-Draft, draft-carleton-workload-authz-grant-02, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-carleton-workload-authz-grant-02>.

A.1. Deferred Request

The client sends the token exchange request of the [FEDERATION] walkthrough with scope=files.write, completion_mode=deferred, and a DPoP proof of key K. The IdP authenticates analysis-client, resolves agent-42, checks the Client Association and Alice's Delegation Authorization, and finds that policy requires Alice's approval for files.write. Alice's ID Token expires in 65 minutes, so a one-hour pending lifetime leaves a grant issued at any point in it its full 300-second lifetime. The IdP records the pending governed request and responds:¶

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
  "error": "authorization_pending",
  "deferral_code": "DEFERRAL_CODE",
  "expires_in": 3600,
  "interval": 5
}

A.2. Approval

Alice receives an approval request on her authenticator, sent by CIBA with this binding message:¶

agent-42 (client analysis-client) asks to write files in acme-data

She authenticates and approves.¶

A.3. Resolution

The client polls, authenticating as in the [FEDERATION] walkthrough and proving K:¶

POST /token HTTP/1.1
Host: idp.example
Content-Type: application/x-www-form-urlencoded
DPoP: IDP_DPOP_PROOF

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adeferred
&deferral_code=DEFERRAL_CODE
&client_id=analysis-client
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth
%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=CLIENT_ASSERTION_2

The IdP re-checks that agent-42 is active, its binding and association still permit the request, Alice's Delegation Authorization still permits files.write, and Alice is active. It issues the ID-JAG the request would have produced, with scope files.write, sub alice-ras, act naming agent-42, client_id analysis-api, cnf.jkt for K, and iat at resolution. The response carries issued_token_type urn:ietf:params:oauth:token-type:id-jag. The client redeems it at the RAS as in the [FEDERATION] walkthrough.¶

A.4. Negative Tests

Each case changes the walkthrough as stated; all other checks succeed.¶

A.5. Deferred Redemption

In this variant, the IdP issues the ID-JAG of the [FEDERATION] walkthrough without approval, and RAS policy for acme-data requires the tenant's data steward to approve each agent redemption for files.read. The client redeems the grant as in the [FEDERATION] walkthrough, adds completion_mode=deferred, and proves the key in the grant's cnf.jkt.¶

The RAS completes the checks of "Grant Validation" in [FEDERATION]: it resolves alice-ras to user-108, correlates agent-42, and finds that the actor gate permits it. It accepts the grant, sets the absolute authorization expiration eight hours ahead, records the pending governed redemption, opens one approval request, and returns the deferred response with expires_in 3600. The steward approves through the RAS's access request service, with an approval expiry two hours ahead.¶

The client polls the RAS as it polled the IdP (Appendix A.3), proving the same key. The RAS re-checks agent-42, user-108, the actor gate, and the approval, and issues the access token of the [FEDERATION] walkthrough: sub user-108, act naming agent-42, cnf.jkt for the key, and an expiration within the approval expiry. The RAS does not record the authorization as eligible for continuation.¶

Each case changes this variant as stated; all other checks succeed.¶