Overview
The first four crosswalks held the model against a threat model, a requirements framework, a threat taxonomy, and the governance frameworks. This one holds it against a candidate problem statement from inside the OAuth conversation. Agent Authorization Use Cases and Gap Analysis is an active individual draft in the OAuth working group’s orbit, written by authors from China Mobile, CNNIC, and Huawei. It catalogs eleven agent scenarios in three categories, runs a gap analysis under each against OAuth 2.0 and its common extensions, and rolls the findings up to six major gaps. Revision 03 (August 25, 2026), the text answered here, adds an opening section naming three core gaps that run through nearly every use case: the authorization context gap, the delegation chain gap, and the mass revocation gap. The editor’s copy runs ahead of the published revision, its issue tracker is where the catalog moves between revisions, and this mapping re-pins at each published revision. The catalog proposes no solution.
The catalog’s first revision developed independently of this family. Later revisions reflect discussion between the efforts: the data-subject requirement echoes an issue filed from this side, and revision 03 acknowledges contributors from those same threads. This mapping evaluates revision 03 on its requirements and does not count that later alignment as independent validation.
The argument here is not a score. Several of the catalog’s gaps need the same connection: an approved task that later credentials, decisions, delegations, and revocations can identify. The Mission proposes that connection. Each enforcement layer still has obligations of its own, and three requirements stay partly open. The crosswalk then maps every row with its source section, so the reading can be checked.
One task, three failures
The catalog’s first use case is a personal assistant. On Monday, Alice asks it to “help me plan a picnic for this Saturday.” It checks her calendar and the weather, researches parks, and on Tuesday afternoon asks for permission to book a spot and add the event to her calendar. Three of the catalog’s gaps appear in that one task.
- The context is lost. Tuesday’s prompt lists scopes like
parks.bookandcalendar.write, and Monday’s instruction is gone. To Alice it reads, in the catalog’s words, “Why does this app want to book a park now?” Her real questions (“Which park did you choose?” “Is there a fee?”) have nowhere to go. - An action runs with no one approving it. Where the booking falls inside a grant the assistant already holds, no fresh approval triggers at all. “The failure is not a bad consent screen, it is the absence of one.”
- Cancelling the task does not reach its permissions. Alice should be able to say “Cancel the picnic planning” and have every permission and pending action for that task revoked without touching her other tasks. OAuth revokes tokens one at a time, and a task is not a token.
The connection the gaps share
Each failure is the same missing object seen from a different side: nothing in the protocol identifies the approved task, so nothing later can be checked against it. The Mission is that object, a durable record of the approved task with an identifier that later credentials, decisions, delegations, and revocations carry. What it fixes depends on the layer enforcing it.
Context travels with the task. The client submits the Mission Intent through PAR, the Authorization Server validates it, commits it with intent_hash, and renders its goal beside the derived authority when Alice approves. A later request for more authority is an Expansion of that specific Mission, approved with the running Mission in view, and Alice’s questions go through Disclosure Interrogation, answered from recorded material rather than from the agent. Committing the Intent does not prove it faithfully represents what Alice said; her check of the rendered goal and bounds closes that gap.
The consequential action gets its own decision. The catalog’s sixth gap says grant-layer tokens prove potential, never the legitimacy of a specific executed transaction, and asks for parameter-bound, non-repudiable evidence of consent at the moment of execution. That split is the one the family’s runtime layer is built on: authority is the upper bound, the permit is the per-action decision bound to concrete parameters by parameter_digest, and action-bound approval, which the runtime profile says a deployment SHOULD require for the high-consequence classes, is the mechanism that asks. A human makes that decision where the deployment routes it to a human Approver. The executing PEP recomputes the digest and reverifies the approval before the effect commits, which is revision 03’s requirement that execution evidence be verified first, and Runtime Evidence’s evidence properties state what the resulting records prove and under which conditions.
Revocation targets the task. The catalog calls the lack of task-level revocation “a major operational and security failure point,” and the diagnosis is exact: OAuth can revoke a token, and a task is not a token. Revoking the Mission stops it on every path the deployment governs, each within its own bound: an issuance-gated path mints nothing new and its outstanding credentials expire within their lifetime, a runtime-enforced path refuses within its published staleness bound, the harness stops resuming, and Child Missions fall with their parent. A path the deployment excluded from Mission enforcement gets nothing from the revocation, and its enforcement-scope statement says so. Mission Management carries the same stop to a compromised principal’s Missions at once.
Asking for more is an admission decision. The catalog’s first gap says agents need a “continuous dialogue” of just-in-time permissions rather than upfront grants. Read carefully, it is the discovery loop specified as a requirement: start narrow, discover the need, ask through a governed channel, and land the widening as a fresh approval. Every turn of that dialogue is an admission decision, and the agent never grants itself scope mid-flight.
A smart-home approval, worked
The catalog’s smart-home scenario generates per-device scopes until the consent screen is unusable. Moving consent to the task grain reduces that, and it still leaves work: mapping the task to each device’s authority, handling devices discovered later, showing consequential limits plainly, and keeping the disclosure, the derived authority, and the enforced bounds aligned. One bounded approval shows how the pieces fit.
Bob approves a morning-routine Mission. Its target resources are the bedroom lights, the thermostat, and the coffee maker. The derived entries allow dimming the lights, setting the thermostat between 66 and 72°F, and starting the coffee maker, each constrained to weekdays between 6:45 and 7:15. The doors are not named. The disclosure renders those entries as statements, with the time window and the temperature range shown as bounds.
Later the agent finds a smart door lock and tries to unlock it at 7:00. Derivation never produces an entry for a resource the Intent did not name, so the PDP refuses the action as out_of_authority and marks the denial requestable. The agent can ask through the discovery loop, and the request is an Expansion: a fresh approval of a successor Mission that names the lock, unless a ceiling Bob consented to earlier already covers that device class, in which case policy adjudicates the drawdown inside it. The original approval never covered the lock, and Bob did not have to anticipate it for the denial to hold.
The example leaves three questions to each deployment: who maintains the mapping from a routine to device entries (the derivation policy, kept per resource), how the disclosure stays readable as devices multiply (the translation floor), and whether a household accepts one approval per new device (a ceiling over a device class is the family’s answer, and it is experimental).
Where the answer is incomplete
Three requirements the family only partly addresses:
- The human’s own signature at execution. The consent link in the execution chain is the deciding infrastructure’s record of the human decision, not the human’s own signature, so non-repudiation against the recorder needs a user-key-signed confirmation the family composes with rather than defines.
- One budget across administrative domains. Partitioned group authority is native, a parent and its children, each attributable, and collapsing differentiated members into one shared grant identity would still trade Law 2 for convenience, the thing the contractor post warns about at fleet scale. What the catalog asks beyond that, one aggregate constraint consumed consistently by branches in separately administered domains, this family does not define: Consumption Metering bounds cumulative spend under one authority, and cross-domain consistency of that counter is open.
- Trust between strangers. Offline attenuation chains prove their own narrowing and the Status List gives a local revocation decision, but trust bootstrapping between organizations with no prior arrangement is deliberately not claimed: projection is trust-scoped, and the portability wager prices exactly this.
Two the family leaves to other layers, and one caution:
- The data subject. Where an agent touches data about a person who is not the resource owner, a Mission’s approval never substitutes for that person’s consent, and the OAuth binding’s Privacy Considerations now say so. Revision 03 asks for more, a way for the data subject to authorize the access, and that belongs to the resource domain’s own lane, which the binding names and which Mission authority never overrides.
- The OS-native half of the bridge. The harness mediates local side effects under Mission state, and expansion is the agent-subject elevation path, but the family does not specify how a Mission maps into OS-native entitlements, sandbox profiles, or elevation dialogs, and it composes with whatever the platforms define.
- Both are individual drafts. Agreement on requirements argues that the problem statement and this solution shape belong in the same venue conversation. It does not show that this architecture is necessary or sufficient, it makes neither one a standard, and the family’s own maturity labels mark nearly every answer below as experimental or a sketch.
The crosswalk
The verdicts here are simpler than the OWASP post’s, because gaps are not threats. Answered means the gap lands on named machinery with a draft behind it, maturity labeled, and the verdict names the smallest adoption bundle that meets the core of the ask: Baseline Issuance (the OAuth binding alone), Runtime-Enforced, or Governed Agent, or else the extension companion the answer needs beyond them. A companion that only adds to an answer does not change its tag. Partial means the machinery covers most of the ask and the remainder is stated. Delegated means the gap belongs to a layer the family composes with rather than supplies. The catalog is outside, the mapping is ours, and every row cites its source section and the machinery so the reading can be re-run.
The catalog’s summary rolls its findings up to six major gaps, and each use case carries sharper asks beneath them. The table answers both grains: the six major gaps first, in the catalog’s order, with the revocation gap split into its two constructions, then fifteen asks from the use-case analyses. Revision 03’s three core gaps land on rows below: the context gap is the first ask, the delegation chain gap is the multi-hop row, and the mass revocation gap is the two revocation rows.
| The gap | Source (revision 03) | What it asks for | The family’s answer | Verdict |
|---|---|---|---|---|
| Pre-approval versus dynamic authorization | §6 | Permissions granted just-in-time as tasks emerge, not all upfront | The discovery loop: start narrow, hit a requestable denial, request, approve, expand as a successor Mission, with Progressive Authorization (experimental) for ceiling-and-drawdown | Answered (needs Expansion) |
| No standardized interactive channel | §6, §4.1.2 | A way to pause a task and ask the user for an intermediate decision, and a clarification dialogue before consent | Deferred Approval makes the approval asynchronous and pollable, ARAP carries the mid-task ask from a requestable denial, action-bound approval puts an approval on each action in the highest classes, and suspended is the pause. The clarification dialogue is Disclosure Interrogation: the Approver’s question channel before the decision, answered from recorded material, with any answer relayed from the agent marked as relayed, because the agent is the injection surface | Answered (Governed Agent, with ARAP) |
| Multi-hop delegation chains | §6, §3.2 | Tokens that represent User to Agent A to Agent B verifiably | The RFC 8693 act chain via the Actor Profile, Child Missions with their own lifecycle and lineage, and offline attenuation whose chains prove their own narrowing, which also answers the managed-services ask that each hop of a sub-provider or tenant hierarchy narrow what it received | Answered (Baseline Issuance, with the Actor Profile) |
| Task-level and Mission-bulk revocation | §6, §3.3 | Revoke one task without touching others, and a principal’s Mission-governed authority at once in an incident | Revocation by mission_id is task-level revocation on the paths the deployment governs, reaching issuance-gated paths within the credential lifetime and runtime-enforced paths within their published bound, cascade reaches the delegation tree, Mission Management carries enumerate-and-bulk-revoke with dry-run first, and the revocation matrix prices the latency | Answered (needs Mission Management for the bulk half) |
| Principal-wide credential and session kill | §4.3.1 | One API call revoking every access token, refresh token, login session, and application authorization an employee holds, across all applications | The credential and session layers the containment matrix names as separate kills with separate owners: agent IAM and the credential issuer. The family’s kill reaches Mission-governed authority, and it composes with those layers rather than supplying an estate-wide token and session surface | Delegated |
| Per-client, not per-group authorization | §6, §4.2.3 | Partitioned per-member authority plus task-level constraints consumed jointly across independently administered branches, one budget spent by many hands | Partitioning is native: a parent Mission with Child Missions gives each branch its own bounded, attributable, revocable slice, with late binding by instance attestation and atomic lifecycle through cascade. Aggregate bounds under one authority are Mission-grain consumption plus Consumption Metering (experimental). Consistent, shared aggregate state across separately administered domains remains open: this family does not define it | Partial |
| Grant-layer versus execution-layer | §6, §4.1.2 | Non-repudiable, parameter-bound proof that a specific high-risk action was consented to at the moment of execution, not just that authority existed | The chain exists with a signer at every link: Consent Evidence commits the rendered disclosure, action-bound approval binds a fresh human decision to the final parameters, the permit carries parameter_digest (the experimental Transaction Authorization profile carries that challenge at the point of use), Mission Runtime Evidence records the decision and the outcome and maps what those records prove under which conditions (evidence properties), the executing PEP recomputes parameter_digest and reverifies any action-bound approval before execution, Approval Governance records who could approve and why, and Audit Transparency makes the set offline-verifiable. The remainder is the ask’s strongest word: the consent link is the deciding infrastructure’s record of the human decision, not the human’s own signature, so non-repudiation against the recorder needs a user-key-signed confirmation the family composes with rather than defines | Partial |
| Authorization context at consent time | §3.1, §4.1.2 | A verifiable context object that carries the user’s original intent to a permission request made later, so the Authorization Server can show it and the user is not asked to approve blind | The Mission Intent is that object: the client submits it through PAR, the Authorization Server validates it and commits it with intent_hash, and the approval renders its goal beside the derived authority. Every later token carries the mission reference, and a later request for more authority is an Expansion of that specific Mission, approved with the running Mission in view. Request Provenance signs the originator, channel, and capture time of the instruction to the exact Intent, and Consent Evidence commits what the Approver saw. Committing the Intent and authenticating its provenance do not prove that the Intent faithfully represents the original instruction; the Approver’s check of the rendered goal and bounds against what they asked for closes that gap | Answered (needs Expansion for the later request) |
| Silent execution within a valid grant | §4.1.2 | A fresh human decision for a high-impact or irreversible action, even when the action falls inside an existing grant | The runtime gates every consequential action at a PDP, and the runtime profile says a deployment SHOULD require an action-bound approval for the high-consequence classes: a fresh approval bound to that action’s final parameters, from an independent Approver or policy authority and never self-issued. The PDP’s requestable approval_required denial is how the runtime asks, and the AuthZEN profile bars auto-approving it in those classes without an independent approver. A human decides each such action where the deployment routes action-bound approval to a human Approver; the agent-compromise-resistant claim makes the approval a MUST and has a component isolated from the agent render its disclosure. The class guard keeps a human on the approval of any Mission that grants those classes | Answered (Runtime-Enforced) |
| Scope explosion | §4.1.3 | Consent that survives a thousand granular scopes | Consent moves to task grain: the Approver consents to one Mission’s derived authority, rendered legibly, instead of a thousand scopes. Mapping the task to each device, handling devices found later, and keeping the disclosure aligned with what is enforced remain work, shown in the smart-home example, and the handbook’s fatigue budget, deployment guidance no draft specifies, governs how many approvals remain | Answered (Baseline Issuance) |
| Conditional policy enforcement | §4.1.3 | Conditions like time windows expressed and enforced, not custom-coded | Per-entry constraints evaluated on every action by the PDP through the AuthZEN profile, with an unknown constraint refusing rather than passing, and resource policy staying authoritative | Answered (needs the Resource Access Profile) |
| Agent-user differentiation | §4.1.4 | A standard way to know an agent is calling, not a human | The identity substrate the family composes with: Client Instance Identification authenticates the client instance, with the attesters a client endorses under Client Attester Endorsement, the Actor Profile’s actor-type classification marks a delegate as an AI agent, and the mission claim adds what the agent is acting for | Answered (Baseline Issuance, with the identity drafts) |
| Caller-class consent | §4.1.4 | Interactive human, platform-native AI, and external delegated agent as distinct classes the caller cannot self-select, consented independently with no inheritance | The class is a governance fact, not a self-claim: the Agent Registry and instance attestation assign it, per-class authority is separate Missions with no ambient inheritance, and the Mission gives the application’s own AI an object to attach consent to even inside a shared client. The family does not define a wire signal separating the app’s AI from the user’s own click within one client | Partial |
| Task-context binding against the confused deputy | §4.1.4 | Bind delegated authority to the originating principal or task context, and verify that binding at the resource server before an action is performed | Every derived token carries the mission reference, the Authority Set derives only from that task, and the PEP checks each consequential action, its parameters, and its actor against the live Mission before the resource sees it (runtime enforcement); a Mission-aware Resource Server can check the same binding itself. The binding confines an injected agent to the approved task. Misuse inside that task’s authority is bounded rather than prevented, which is why trifecta containment and tight scope remain the defense there | Answered (Runtime-Enforced) |
| Constraint expression | §4.1.4 | Rate limits, data caps, and time bounds, not binary scopes | Structured constraints that only tighten, expiry capped by the Mission’s clock, and Consumption Metering (experimental) for cumulative budgets and call caps | Answered (needs Resource Access and Consumption Metering) |
| Cross-agent audit correlation | §4.2.4 | A reserved, interoperable identifier so one task’s actions join across agents, hops, and logs | The mission claim is that reserved object: every derived token carries {id, issuer}, every decision and execution record binds to it, and the audit join is deterministic rather than stitched from timestamps (The Agent Runtime and Audit), with Audit Transparency making the joined trail verifiable | Answered (Runtime-Enforced) |
| Verifiable autonomous action records | §4.3.1 | A durable, non-repudiable, potentially offline-verifiable record that a specific agent took a specific action, under which policy, triggered by what, at what time | Mission Runtime Evidence, the evidence object’s normative home, attests the agent, the action and its parameters, the policy_version, and the time, joined on the Mission, and Audit Transparency’s Transparent Statements, a signed statement plus its receipt, verify offline against a non-equivocating log. Signed records establish attributable assertions: a verified record proves which emitter asserted what under its published key, and does not by itself prove that the reported effect occurred or that the emitter was honest (evidence properties) | Answered (Runtime-Enforced) |
| Batched authorization across trust domains | §4.2.5 | One batch authorization operation across multiple providers, with fine-grained authority delegated to the sub-agent executing each sub-task | The consent grain is answered: one approval whose Authority Set spans the batch, Child Missions narrowing per sub-agent, and Cross-Domain Projection carrying the Mission into each domain with ID-JAG issuance gated on Mission state, the chaining substrate in the RFC Editor queue. This family does not define a single acquisition operation across independently administered authorization servers; Batch Authorization Delegation, a proposed individual draft the catalog cites, requests a batch of fine-grained, actor-bound permissions in one request | Partial |
| Stranger-verifiable cross-organizational delegation | §4.2.6 | Verify accountability, attenuated delegation, the acting principal, and revocation status across organizations with no bilateral setup and no synchronous callbacks | Offline attenuation chains prove their own narrowing, the Mandate is the portable statement of committed facts, and the Status List gives a local decision within a published staleness bound, and the experimental Cross-Organizational Delegation profile carries the attenuation chain across organizational domains. Trust bootstrapping between strangers is deliberately not claimed: projection is trust-scoped, and the portability wager prices exactly this | Partial |
| The ungoverned API key | §4.1.6 | A user-authored, scoped, revocable grant to a service that has no authorization server and no front channel at all | Mediated custody is the reachable slice: a handler holds the static key the agent never sees, each use is permit-bound and Mission-gated, and the standalone MAS supplies the governance object without the service changing. A standard front-channel-free grant protocol at a service with no authorization server is substrate the family composes with, not machinery it supplies | Partial |
| The data subject who is not the resource owner | §4.2.2 | A mechanism for the data subject to authorize access to data about them, and a representation of the authority that permits it | The OAuth binding now states the boundary in its Privacy Considerations (Third-Party Data Subjects): Mission approval is not, by itself, a data subject’s consent; the resource domain’s own lane evaluates any required consent or other basis and refuses without it; and a verified consent reference can be recorded as submission_evidence, as provenance and policy input only, not carried on the mission claim. Least exposure is the input-side discipline. Both halves of the ask, the data subject’s own authorization and a representation downstream parties can rely on, belong to that resource domain, and no OAuth semantics yet name the data-subject relationship | Delegated |
| The OS permission bridge | §4.1.5 | A protocol-level link between a task’s lifecycle and local OS permissions, and an elevation mechanism designed for agents as non-human subjects | The task lifecycle is a protocol object: Mission state is observable through Status and Signals, and the harness consumes it as the PEP for the local paths no gateway sees (files, shell, spawn, resume), stopping them when the Mission ends. Elevation for an agent subject is an Expansion: a governed request for more authority, approved as a successor Mission and attributed to the agent through the actor chain. Expansion alone puts a human on every elevation, so policy-adjudicated drawdown within a human-approved ceiling under Progressive Authorization (experimental) is what keeps routine elevation automatic, with the class guard keeping a human on the high-consequence classes. The family does not specify a binding of Missions into OS-native permission systems or their elevation dialogs | Partial |
For reference, the table’s 22 rows record thirteen answered, seven partial, and two delegated. Eight of the thirteen are answered within the adoption bundles, three of them at Baseline Issuance, one on the OAuth binding alone and two with identity drafts it composes with, and five need an extension companion: Expansion for the two rows about authority requested after approval, Mission Management for bulk revocation, and the Resource Access Profile for expressed constraints, with Consumption Metering for cumulative budgets. The rows mix the summary gaps with the detailed asks beneath them, and Answered means named machinery with a draft behind it, not demonstrated interoperability or a validated deployment, so the count is not a coverage score.
The eleven use cases
The catalog’s scenarios each land on a named pattern rather than a new one. The personal assistant and the smart home are Missions with standing charters over consumer resources, and the category does not care that they are not enterprise. The third-party SaaS proxy is the issuance profile’s home game. The first connection with no front channel is mediated custody’s slice of an ungoverned world: a handler holds the static key, each use is permit-bound, and the standalone MAS supplies the governance object the service never built. The OS resources case is the harness’s local-PEP slice, with expansion as the agent-subject elevation path and the OS-native remainder in the table above. Business process automation and the coordinated task group are a parent Mission fanning out through Child Missions. The DNS maintenance agent is the standing agent again, cycling authority under a charter, and revision 03’s ask for a standard DNS authorization type is vocabulary for the DNS community to define, which the Resource Access Profile’s entries carry without defining. Managed services across organizations are cross-domain projection, with each sub-provider or tenant hop narrowing what it received, as a Child Mission where one issuer hosts the hierarchy and through offline attenuation where the hop crosses issuers, and delegation between fully provisioned organizations adds the Mandate and the Status List to it, with the stranger-trust remainder priced in the table. And automated incident response is Mission Management’s reason to exist: enumerate a compromised principal’s active Missions and bulk-revoke, dry-run first, with the kill switch reaching issuance, permits, harnesses, and sub-agents on the paths each of them governs.
A test anyone can run
Approve two tasks for the same agent. Delegate part of one to a sub-agent, then cancel that task while a credential and a permit for it are still outstanding. Each covered enforcement point must identify the canceled work and refuse it within its published bound, a path excluded from Mission enforcement does nothing and its enforcement-scope statement says so, and the other task keeps running. The evidence must show which boundary stopped each attempted action. That is a test this family has to pass, and so should any design that claims to close these gaps.