Overview
The first four proofs held the model against a threat model, a requirements framework, a threat taxonomy, and the governance frameworks. This one holds it against the framing that matters most for the venue conversation: 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. Revision 02 (August 2026) is the text answered here. The editor’s copy runs ahead of the published revision, its issue tracker is where the catalog moves between revisions, and this table re-pins at each published revision. 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. It proposes no solution, which is exactly what makes it the right test: a catalog of what is missing, written without this family in mind.
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. 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. And one caution rides along, the same one the whole chapter carries: the catalog is outside, the mapping is ours, and every row cites the machinery so the reading can be re-run.
The gaps, answered
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 twelve asks from the use-case analyses.
| The gap | What it asks for | The family’s answer | Verdict |
|---|---|---|---|
| Pre-approval versus dynamic authorization | Permissions granted just-in-time as tasks emerge, not all upfront | The admission model plus 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 |
| No standardized interactive channel | A way to pause a task and ask the user mid-flight | Deferred Approval makes the approval asynchronous and pollable, ARAP carries the mid-task ask, action-bound approval puts a human on the highest classes, and suspended is the pause | Answered |
| Multi-hop delegation chains | 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 | Answered |
| Task-level and Mission-bulk revocation | Revoke one task without touching others, and a principal’s Mission-governed authority at once in an incident | The bullseye: revocation by mission_id is task-level revocation, cascade reaches the delegation tree, Mission Management carries enumerate-and-bulk-revoke with dry-run first, and the revocation matrix prices the latency | Answered |
| Principal-wide credential and session kill | 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 | 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, with no standard answer on any side | Partial |
| Grant-layer versus execution-layer | 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, 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 |
| Scope explosion | 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, and the fatigue budget is managed rather than wished away | Answered |
| Conditional policy enforcement | Conditions like time windows expressed and enforced, not custom-coded | Per-entry constraints evaluated on every action by the PDP through the AuthZEN binding, with an unknown constraint refusing rather than passing, and resource policy staying authoritative | Answered |
| Agent-user differentiation | A standard way to know an agent is calling, not a human | The identity substrate the family composes with: the Client Instance Assertion and the AI Agent Instance Profile’s attested instance identity and provenance, with the mission claim adding what the agent is acting for | Answered |
| Caller-class consent and internal-AI attachment | Interactive human, platform-native AI, and external delegated agent as distinct classes the caller cannot self-select, consented independently with no inheritance, including an attachment point for the application’s own AI | 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. What no standard supplies yet is the wire signal separating the app’s AI from the user’s own click within one client | Partial |
| Constraint expression | 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 |
| Cross-agent audit correlation | 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, authority_hash}, 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 |
| Verifiable autonomous action records | 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 | Answered |
| Batched authorization across trust domains | 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. What no protocol defines, here or anywhere, is a single acquisition operation across independently administered authorization servers | Partial |
| Stranger-verifiable cross-organizational delegation | 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 | 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 | Authorization evidence that makes third-party data access legible as such and names whose authority permits it | The boundary the family states: a Mission’s approval never substitutes for data-subject consent, least exposure is the input-side discipline, and the legibility requirement is filed against the issuance profile as issue #344, open at this writing | Partial |
| The OS permission bridge | Cloud-level intent connected to fine-grained local OS permissions | The harness is the PEP for the local paths no gateway sees (files, shell, spawn, resume), which is the slice the family supplies. Bridging Missions into OS-native permission systems is a substrate nobody has built | Delegated |
Ten answered, seven partial and two delegated with the remainders stated, and none waved away. The striking thing about the tally is the direction of fit: the catalog began as a problem statement with no solution in mind, and its gap analysis reads like this family’s table of contents. One honesty note rides the re-pin. The independence claim belongs to revision 01, which was written with no knowledge of this family, and the convergence argument rests on that revision’s content. Everything from revision 02 onward arrived after contact between the two efforts, the data-subject requirement echoes an issue filed from this side, and the editor’s copy now acknowledges contributors from those same threads, so the newer rows are answered on their merits and claimed as convergence evidence not at all. The bridge post made the same observation about the card chapter’s build lists. Two catalogs of what is missing keep enumerating the same architecture, and only one counts as evidence: the catalog’s original revision, written with no knowledge of this family. The card chapter’s build lists are the same author teaching the same design, a rhyme rather than a witness.
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 the honest 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. Managed services across organizations are cross-domain projection, 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.
Four gaps worth a closer look
The grant-versus-execution gap is the runtime contract, asked for from outside. The catalog’s new 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, action-bound approval puts a fresh human decision on the highest classes, and Audit Transparency makes the resulting evidence tamper-evident across domains. The open refinement is naming the execution-evidence property cluster as one citable requirement set, filed as issue #343. The editor’s copy sharpens the same demand from the use-case side, naming silent execution within a valid grant: a high-impact action no human specifically approved, because nothing asked. That is the class guard’s reason to exist, and the catalog’s own line, “the failure is not a bad consent screen, it is the absence of one,” states the runtime gate’s premise exactly. That ask enters the table when the revision carrying it publishes.
Task-level revocation is the gap the Mission was born for. The catalog calls the lack of it “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 a task today means finding every token, cached connection, and sub-agent that serves it, which is the archaeology the handbook’s whole first chapter dramatizes. The family’s answer is the object itself: the task has an identifier, revocation targets it, and every projection (tokens, permits, sessions, children) dies with it within a published bound. Where the catalog asks for an API, the family answers with an object, because task-level revocation is only coherent if the task exists.
The paradigm mismatch is the admission model, seen from the other side. The catalog’s first gap says agents need a “continuous dialogue” of just-in-time permissions rather than upfront grants, and read carelessly, that sounds like the runtime intent inference this handbook rejects. 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. The dialogue the catalog wants is real, and every turn of it is an admission decision, never the agent granting itself scope mid-flight. The difference between those two readings is the difference between the category and a loophole.
Scope explosion is a consent-grain problem, not a scope-count problem. The catalog’s smart-home scenario generates thousands of per-device scopes and an unusable consent screen, and the instinct is to fix the screen. The family’s answer moves the grain instead: the human approves one Mission whose Authority Set the issuer derives, and the thousand fine-grained entries live inside the derivation, rendered as a legible disclosure rather than a scope list. The consent screen failed because it asked a human to compile authority by hand. The approval event succeeds because the compilation is the issuer’s job, and the human judges the result.
The honest remainders
- The shared budget across administrative domains is real and open. 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 reworked catalog asks beyond that, one aggregate constraint consumed consistently by branches in separately administered domains, has no standard answer on any side: Consumption Metering bounds cumulative spend under one authority, and cross-domain consistency of that counter is unsolved.
- The OS bridge is real and unbuilt. The harness mediates local side effects, and nothing in the family translates a Mission into OS-native entitlements or sandbox profiles. That is a substrate the ecosystem has not standardized, and the family composes with whatever emerges rather than pretending to supply it.
- The data subject is a boundary, not a feature. 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 catalog’s legibility requirement, evidence that names whose authority permits third-party access, is filed against the issuance profile as issue #344, open at this writing.
- The catalog and the family are both individual drafts. The convergence argues that the problem statement and this solution shape belong in the same venue conversation. It does not make either one a standard, and the family’s own maturity labels say which answers are stable design and which are experimental.
The close is the same one every proof in this chapter reaches from a different direction. The catalog asks what OAuth cannot say about an agent’s work: what it is, who approved it, whether it still stands, and how to end it everywhere at once. Those are the six questions and the five laws in requirements clothing, and the fact that a gap analysis written from inside the OAuth conversation keeps arriving there is the strongest evidence yet that the missing layer is not one proposal’s opinion.