Agent Authorization use cases and gap analysis

Core Use Cases and Gap Analysis This section explores different categories of use cases, providing a concrete example for each, and analyzes the gaps in the existing OAuth 2.x framework. For each use case, we examine what can be achieved with existing tools and, more importantly, what is missing.

Category 1: Personal & Consumer Scenarios

Authorization Requirement Summary The personal and consumer use cases share several recurring authorization requirements that challenge the traditional, static, and upfront nature of OAuth 2.0 grants. These requirements focus on providing user-centric context, control, and lifecycle management for agent-delegated authority.

Requirement Theme	Use Cases and Forms
Dynamic & Contextual Authorization	UC1: Authorization with task context; UC2: Conditional authority (based on event or time); UC4: Just-in-time permission requests.
Granular & Constrained Authority	UC1, UC3: User-defined constraints (e.g., spending limits); UC2, UC4: Fine-grained permissions (for devices, files); UC3: Agent-specific policies (e.g., rate limits); UC5: User-defined scopes for headless services.
Differentiated Actor Identity	UC3: Distinguishing human vs agent, between different agent classes.
Task-Oriented Lifecycle Management	UC1, UC4: Task-bound revocation.; UC2: Bulk client revocation; UC5: Headless bootstrapping of credentials.
Verifiable, Action-Specific Consent	UC1: Approval of final action parameters at execution time.

Use Case 1: Personal Digital Assistant

Scenario Description: A user gives a high-level, natural language command to their AI assistant. The assistant must decompose this command into multiple steps and interact with various services to fulfill the request.
Example: On Monday morning, Alice tells her AI assistant, "Help me plan a picnic for this Saturday." The assistant begins its work autonomously:
1. It first checks Alice's calendar for availability (requires calendar.read).
2. It then checks the weather forecast for Saturday (requires weather.read).
3. Seeing the weather is good, it spends some time researching nearby parks based on Alice's past preferences (requires maps.searchand profile access).
4. On Tuesday afternoon, after identifying the perfect spot, the assistant determines it needs final authorization to book the picnic spot (requires parks.book) and add the event to Alice's calendar (requires calendar.write).
The assistant now presents an authorization request to Alice.
Challenge: Context Collapse and the Erosion of Informed Consent:
This scenario highlights a fundamental challenge to the traditional OAuth 2.0 model, which stems from the temporal decoupling of task initiation and authorization.
- Context Collapse: The authorization request Alice receives on Tuesday afternoon is a simple prompt listing scopes like parks.book and calendar.write. The original context—the "picnic planning" instruction from the previous day—is lost. To Alice, the request is at best confusing ("Why does this app want to book a park now?") and at worst, indistinguishable from a sophisticated phishing attack. The traditional OAuth consent screen, designed for immediate, in-context requests, fails to provide the necessary assurance for the user to make a safe and informed decision.
- Inadequacy of Binary Choices: Alice's only options are "Grant" or "Deny." However, her real question might be, "Which park did you choose?" or "Is there a fee?" The current framework provides no mechanism for this crucial dialogue. Denying the request causes the agent's task to fail, while granting it feels like signing a blank check.
- Task-Level Revocation: Alice should be able to say, "Cancel the picnic planning," and have all permissions and pending actions related to this specific task instantly revoked, without affecting other tasks the agent might be performing.
Authorization Requirements:
- Authorization Context: The authorization request should carry sufficient task and action context for the user to understand why the requested authority is needed.
- Task-Scoped Revocation: The user should be able to revoke authority associated with a specific task without affecting unrelated tasks performed by the same agent.
- Pre-Authorized Constraints: Structured constraints previously approved by the user should remain associated with subsequent actions so that compliance can be checked at execution time.
- Admission-to-Execution Binding: When execution relies on an earlier admission based on originator authorization, applicable policy, or prior consent, the execution endpoint should be able to verify the admission basis and the scope and constraints attached to it.
- Action-Specific Approval: When fresh user approval is required for a high-impact or irreversible action, the approval should be bound to the concrete action parameters and verified before the action takes effect.
Gap Analysis:
This use case does not imply that OAuth itself should be responsible for parsing user intent (the agent's job) or orchestrating the task (the agent framework's job). Instead, it reveals a critical gap in the authorization experience when interacting with autonomous systems.
- What Works (Partially): The OAuth Authorization Code flow can be used to get initial permissions. Refresh Tokens can maintain the agent's session.
- What's Missing (The Gap):
  - No Standard for Authorization Context: The core gap is the lack of a standardized mechanism to carry the justification for the request from the agent to the user via the Authorization Server. OAuth's model, designed for immediate user-initiated flows, implicitly relies on the user's short-term memory to provide context. This assumption breaks down in agentic workflows. There is no standard way for the agent to pass a cryptographically verifiable "context object" (e.g., "This is for the picnic you requested on Monday") that the AS can present to the user.
  - No Standardized Interactive Consent Flow: There is no standard OAuth mechanism for an Authorization Server to facilitate a "clarification dialogue." The AS acts as a simple gatekeeper with a static grant/deny choice. It cannot "pause" the flow to allow the user to query the agent for more details (e.g., "Show me the park details") before consenting to the parks.book scope. This logic is currently left to complex, proprietary application-layer implementations.
  - Impractical Task-Level Revocation: OAuth Token Revocation () revokes a single token. To achieve task-level revocation, the application would need to build and maintain a complex, non-standard mapping of tasks to all associated tokens. There is no standard way to issue a single command like "revoke all tokens and authority related to 'picnic-task-123'."
  - No Standard Binding of Pre-Authorized Constraints to Execution: When the user has previously approved structured constraints on an action, existing grant-layer mechanisms do not provide a common way to bind those constraints to the concrete action performed later and verify that relationship at execution time. states this T0-to-T1 constraint-binding problem and defines requirements without proposing a mechanism.
  - No Standard Admission-to-Execution Binding: When a request is admitted based on originator authorization, applicable policy, or prior consent rather than a fresh user decision, existing mechanisms do not define how the execution endpoint verifies that admission basis or ensures that the concrete action remains within the admitted scope and constraints.
  - No Standard for Execution-Layer Evidence: At the moment of financial commitment (the final "Book" step), a simple access token representing Grant-Layer Authority (e.g., a parks.book scope) is insufficient. The core requirement is for Execution-Layer Evidence: a non-repudiable, cryptographic proof that binds the user's explicit, real-time consent to the specific parameters of the transaction (e.g., "Book picnic spot at 'Sunnyvale Park', cost $25"). This evidence serves as proof of the human's decision at the moment of execution, proving what the user agreed to, not just that the agent possessed the authority to book something. The existing framework lacks a standard for generating or verifying such evidence. Where such evidence is required, it must be verified before the high-impact or irreversible effect is committed.

Use Case 2: Smart Home & Automation

Scenario Description: A central home hub agent manages various IoT devices based on pre-defined rules or real-time events.
Example: Bob sets up a "Good Morning" routine. When his alarm goes off at 7 AM on a weekday, the home hub agent is authorized to:
1. Slowly turn on the bedroom lights (device: bedroom_light, capability: brightness).
2. Set the thermostat to 70°F (device: thermostat, capability: set_temperature).
3. Start the coffee maker (device: coffee_maker, capability: on_off).
Authorization Requirements:
- Persistent Delegation: After a one-time setup, the agent must be able to perform these actions daily without Bob's intervention.
- Fine-Grained Device & Capability Permissions: The agent should be authorized to control the brightness of the bedroom_light, but not, for example, to unlock the front_door.
- Conditional or Event-Driven Authorization: The permissions should only be usable when specific conditions are met (e.g., time=7AM AND day=weekday).
- Bulk Revocation: When Bob sells his house, he needs a simple way to revoke all permissions for all devices from his home hub with a single action.
Gap Analysis:
- What Works (Partially): Refresh Tokens are well-suited for persistent delegation. Scopes can be defined with high granularity (e.g., device:bedroom_light:brightness).
- What's Missing (The Gap):
  - "Scope Explosion" and Usability: In a home with hundreds of devices and capabilities, presenting the user with a list of thousands of scopes to approve is unmanageable. The OAuth consent screen was not designed for this scale.
  - No Standardized Policy Enforcement: OAuth grants what an agent can do, but not when or under what conditions. The logic to enforce time=7AM is outside the protocol and must be custom-built into the agent or the device's resource server, leading to inconsistent and non-interoperable implementations.
  - No Standardized Bulk Revocation: is for revoking one token at a time. There is no standard API to "revoke all tokens for user Bob" or "revoke all tokens issued to the home hub client." This is a critical administrative and security gap, forcing reliance on proprietary AS-specific APIs.

Use Case 3: Agent as User's Full Proxy to Access Third-Party Tools

Scenario Description: A user authorizes an agent to use a third-party service on their behalf. The service, however, was designed for human interaction and has no built-in awareness of automated agents, leading to potential misuse or policy violations.
Example1: Charlie authorizes his personal research assistant agent to use his subscription to an academic paper database. The agent, acting as Charlie, begins downloading hundreds of papers for a literature review. The database service detects this high-frequency activity, flags it as a potential DDoS attack or data scraping, and temporarily locks Charlie's account, disrupting both the agent's task and Charlie's own access.
Example2: The database service later adds its own built-in AI features: an AI summarizer that processes users' saved papers. Charlie now faces three distinct classes of caller against the same API surface: his own interactive sessions, the service's built-in AI, and his external research agent. He may be comfortable with the built-in summarizer processing his library but not an external agent, or the reverse. His consent decision for one class says nothing about the others.
Authorization Requirements:
- Agent-User Differentiation: : The third-party service must be able to reliably distinguish between requests coming directly from Charlie and requests made by his agent.
- Agent-Specific Policies: The service needs a way to apply different policies (e.g., stricter rate limits, restricted API access) to the agent without impacting the human user's normal access rights.
- Delegated Authority with Constraints: The authorization given to the agent should be a constrained subset of the user's full permissions (e.g., "can search and download, but no more than 100 papers per hour").
- Caller-Class Differentiation: Beyond distinguishing the agent from its user, the service must be able to distinguish among classes of caller (at minimum the interactive human session, the application's own platform-native AI, and external user-delegated agents) in a way the caller cannot self-select.
- Independent Per-Class Consent: The user must be able to grant or deny consent for each caller class independently, with no inheritance between classes: consent for one class must not imply consent for any other.
- An Attachment Point for Internal-AI Consent: The application's own AI features typically never traverse the authorization layer at all, so there is currently nothing to attach a consent decision to for that class.
Gap Analysis:
- What (partially) works: OAuth allows a user to delegate access to a client (the agent). The scope parameter can limit which APIs the agent can call.
  - What Works (Partially): OAuth allows a user to delegate access to a client (the agent). The scope parameter can limit which APIs the agent can call.
- What's Missing (The Gap):
  - No Standard Agent Identifier: There is no standard OAuth claim or parameter that explicitly signals "this request is from an automated agent." Resource servers are left to guess based on non-standard signals like User-Agent strings or unusual traffic patterns.
  - Inability to Express Constraints: The standard scope mechanism is binary (permission is granted or not). It cannot express or enforce nuanced constraints like rate limits, data volume caps, or time-of-day restrictions as part of the authorization grant itself.
  - Confused Deputy Risk: Without clear differentiation, the service provider cannot tell if high-volume activity is malicious (account takeover) or a legitimate but overly aggressive agent. Their only recourse is often to block the user's account entirely.
  - No Standard Caller-Class Representation: Beyond the human-versus-agent distinction, there is no standard representation of a caller class, and no standard way to express consent that is evaluated per class without inheritance between classes.
  - Internal AI Is Invisible to Authorization: Because the platform's own AI typically operates inside the application boundary, no standard consent mechanism applies to it at all, leaving users no way to express "external agents I delegate may process my data, but the platform's AI may not," or the reverse.

Use Case 4: Agent as User's Proxy to Access Operating System Resources

Scenario Description: An agent running on a user's device (e.g., a laptop or smartphone) needs to perform tasks that require access to local resources like files, applications, or system settings.
Example: Diana asks her desktop agent, "Clean up my downloads folder and free up disk space." To do this, the agent needs permission to read and delete files within /home/diana/downloads. However, to be "helpful," the agent might also try to clear system-wide caches, which requires elevated, system-level permissions.
Authorization Requirements:
- Fine-Grained Resource Access: The agent should be granted access only to the specific files or settings needed for a task (e.g., a single folder), not the user's entire home directory or full system access.
- Task-Scoped Permissions: Permissions should be granted for the duration of a specific task ("clean downloads folder") and automatically revoked upon completion.
- Secure Privilege Escalation: If a task requires elevated permissions, there must be a secure, user-approved mechanism for the agent to request them just-in-time, rather than running with high privileges constantly.
Gap Analysis:
- What Works (Partially): Modern operating systems have their own permission models (e.g., app sandboxing, runtime permission prompts).
- What's Missing (The Gap):
  - Architectural Mismatch: OAuth is a framework for network-based delegated authorization. It is not designed to manage local, process-level OS permissions. There is a fundamental mismatch between the two models.
  - Lack of a Standard Bridge: There is no standard protocol to connect an agent's high-level intent (often determined in the cloud) to a secure, fine-grained grant of local OS permissions on the device.
  - Over-Privileging by Default: Due to the lack of a standard bridge, developers often resort to a dangerous workaround: the agent's local component is installed with broad, persistent permissions (e.g., running with the user's full rights or even as a system service). This completely bypasses the principle of least privilege and creates a significant security risk.

Use Case 5: First Connection to a Service with No Authorization Front Channel

Scenario Description: Scenario Description: A user wants their agent to access a service that has no authorization server relationship, its own or a delegated one, and exposes no browser-facing authorization endpoint. The agent runs in a headless or remote environment with no co-located browser. Neither side can present the front channel that existing flows assume.
Example: Dana subscribes to a note-taking service that exposes a plain REST API with no authorization server and no browser-facing authorization endpoint, as is common for services and MCP servers that predate or do not implement an authorization framework. She wants her personal assistant agent, which runs on a cloud host, to file notes for her. To make the first connection, Dana needs to: 1. Grant the agent scoped access (notes.write, but not account.manage). 2. Set a lifetime for that access and retain the ability to revoke it. 3. Get the resulting credential to the agent, which has no browser and cannot complete a redirect-based flow.

Today her only practical option is to copy a static API key into the agent's environment variables: long-lived, all-or-nothing, and invisible to her after setup.

Authorization Requirements:
- Front-Channel-Free Bootstrapping: The first-connection grant must be possible when neither the service nor the agent can present a browser-based interaction channel.
- User-Authored Grant: The user, not the agent, needs a way to initiate the grant and set its scopes and lifetime, since there is no authorization request for the agent to redirect her to.
- Scoped, Revocable Credential: The resulting credential must carry a constrained scope and lifetime and remain revocable by the user, in contrast to the static API key it replaces.
Gap Analysis:
- What Works (Partially): The Device Authorization Grant [RFC8628] removes the co-located browser requirement on the client side. Static API keys work operationally, which is why they are the de facto practice.
- What's Missing (The Gap):
- A verification page is still assumed: [RFC8628] presumes an authorization server with a browser-facing verification page, and the client initiates the request and proposes the scopes. It does not cover the case where no such page exists because the service has no front channel at all.
- No standard first-connection grant: There is no standardized way for the user to grant scoped, revocable access and for the agent to obtain the resulting credential when no front channel exists on either side. This precedes the flows in the existing use cases; Use Case 1's gap analysis, for example, notes that the Authorization Code flow can obtain the initial permissions, which assumes that front channel is available.
- The workaround is the anti-pattern: Environment-variable API keys are long-lived, over-broad, and invisible to the user after setup; these are the same over-privileging properties Section 5 warns against.

Category 2: Enterprise & Business Process Scenarios

Authorization Requirement Summary The enterprise and business-process use cases share several recurring authorization requirements, although the form of each requirement depends on the workflow structure and trust boundaries involved.

Requirement Theme	Use Cases and Forms
Constrained Delegated Authority	UC6: least privilege at each step; UC7: authority partitioned by branch; UC8: domain- and operation-specific permissions; UC9: scoped delegation to sub-providers and tenants; UC10: attenuation at each delegation hop
Verifiable Delegation Provenance	UC6: verification of the multi-hop authorization path; UC8: verification of the Registrant--Registrar--Registry delegation; UC10: verification of attenuated authority and the represented principal across organizations
Common Task Identifier Across Hops	UC6: common `claim_id`; UC8: common audit context identifier across agent hops
Revocation & Authorization Lifecycle	UC7: termination of task-group authority; UC8: task-specific revocation; UC10: revocation with bounded staleness
Cross-Domain Authorization	UC9: authorization across sub-provider administrative domains; UC10: authorization between independently administered organizations

The summary includes only authorization requirements that recur across multiple use cases. Use-case-specific requirements or gaps remain with the individual scenarios, such as data-subject authorization and execution-layer evidence in UC6, aggregate constraints and late-bound members in UC7, the standardized representation of a cross-agent audit identifier in UC8, batched authorization in UC9, and stranger verifiability in UC10.

Use Case 6: Complex Business Process Automation

Scenario Description: A task is passed through a chain of specialized agents, each performing one step of a larger business process.
Example: An automated insurance claim process:
1. Agent A (Intake): Receives a claim from a customer and is authorized to read the customer's policy. It passes the claim to the next agent.
2. Agent B (Verification): Receives the claim from Agent A. It is authorized to access external databases to verify the details of the incident. It then passes the verified claim to Agent C.
3. Agent C (Adjudication): Receives the verified claim from Agent B. It is authorized to run a risk assessment and approve or deny the claim. If approved, it delegates the final action to Agent D.
4. Agent D (Payment): Receives the approved claim from Agent C. It is authorized only to execute a payment to the customer's bank account for the approved amount.
Authorization Requirements:
- Verifiable Delegation Chain: The final agent (Payment Agent D) and the resource server (the bank's API) must be able to cryptographically verify the entire authorization path: Customer -> Agent A -> Agent B -> Agent C -> Agent D.
- Principle of Least Privilege at Each Step: Agent B should have no payment authority, and Agent D should have no access to the customer's policy details. The permissions must be strictly constrained at each step in the chain.
- Auditable Context: The entire process must be tied to a single, auditable claim_id that is securely passed along the chain.
- Data Subject: Where an agent accesses data describing a Data Subject who is not the Resource Owner, the authorization evidence MUST make the third-party access legible as such, and the catalogue MUST name whose authority permits it.
- Execution-Layer Evidence for Final Action: The final payment action by Agent D must not only be authorized by the delegation chain (Grant-Layer Authority) but must also generate verifiable Execution-Layer Evidence. This evidence must bind the specific payment details (amount, recipient) to the full, verifiable delegation chain and the original claim_id, creating an undeniable record that the specific transaction was legitimate and explicitly sanctioned.
Gap Analysis:
- What Works (Partially): OAuth 2.0 Token Exchange introduces the act (actor) claim, which provides a primitive to show that one agent is acting on behalf of another. This is a foundational building block.
- What's Missing (The Gap):
  - No Native Support for Chains: A standard OAuth token represents a simple, two-party delegation (User -> Agent A). It cannot natively represent a multi-step chain (User -> A -> B -> C). While the act claim from helps, there is no standard for how to nest these claims to create a verifiable, multi-hop chain. This is a major architectural gap.
  - Lack of Standardized Context Passing: There is no standard field in an OAuth token to carry the claim_id securely through the process. Developers resort to custom claims in a JWT, which harms interoperability.

Use Case 7: Coordinated Task Group

Scenario Description: A coordinating agent decomposes a user's request into subtasks and delegates them to multiple specialized agents. Unlike a delegation chain (Use Case 6), authorization in a task group may need to be partitioned across sibling branches, while some task-level constraints and lifecycle state remain shared across the group .
Example 1 -- Partitioned Authorization: A payment assistant coordinates agents from multiple banks to compare promotional discounts for a payment. Each bank agent should receive only the permissions and authorization context required for its own bank. Permissions or sensitive context assigned to one branch should not automatically be available to another branch.
Example 2 -- Shared Task Constraint: A user asks a travel assistant to arrange a business trip and authorizes a total spend of at most 100 units for the trip. The assistant delegates flight booking to a flight agent and hotel booking to a hotel agent operating in separately administered domains. The user has not fixed how the limit is divided between the two. Each delegated authorization may be valid independently, while their combined use may exceed the task-level limit.
Example 3 -- Late-Bound Members: A health assistant decomposes a user's request into health-data collection, status prediction, and advice generation. Some sub-agents may be selected upfront, while others may be selected during execution as intermediate results determine which additional capabilities are needed.
Authorization Requirements:
- Branch-Level Partitioning: The authorization framework must support partitioning permissions and relevant authorization context among members according to their subtasks and resource domains.
- Task-Level Aggregate Constraints: The authorization framework must support binding multiple delegation branches to constraints that apply to and are consumed by the task as a whole.
- Late Binding of Members: Members selected during task execution must be able to obtain appropriately constrained authority under the existing task authorization.
- Group Lifecycle: Authority associated with the task group must be able to be terminated as a unit when the task ends or its authorization is revoked.
Gap Analysis:
- What Works (Partially): Existing mechanisms address several parts of this problem. considers centralized authorization for static and dynamic task groups. allows a client to express how permissions and authorization context are partitioned across multiple actors in an authorization request, including scoping the permitted actor per authorization_details entry. Token Exchange , Identity Chaining , and Transaction Token Chaining provide building blocks for propagating delegated authority and context along individual delegation chains.
- What's Missing (The Gap):
  - No Common Task-Group Authorization Model: Existing mechanisms can authorize or constrain individual members, but do not define a common interoperable binding that relates independently delegated authorities to the same task group, including late-bound members and a common lifecycle.
  - No Shared Authorization State Across Branches: Per-member partitioning does not address constraints consumed jointly by multiple branches. Across separately administered domains, there is no standard way for delegated authorizations to reference and consistently enforce the same task-level aggregate authorization state.

Use Case 8: Automated DNSSEC DS Record Maintenance Agent

Scenario Description: This case follows the multi-agent RRR (Registrant-Registrar-Registry) model defined in draft-ietf-dnsop-ds-automation-09. A corporate domain owner deploys chained agents to fully automate DS record updates during DNSSEC KSK rollovers, zone bootstrapping, and zone deletion, relying on CDS/CDNSKEY signals between child authoritative zones and parent registry systems.
Example: The whole workflow runs unattended under a one-time delegated permission from the domain registrant, forming a delegation chain: Registrant --> Registrar Agent --> Registry Agent.
- Zone Agent: Publishes consistent CDS/CDNSKEY records on all name servers after key rollover.
- Registrar Agent: Pulls and validates CDS data, forwards DS update requests to the registry.
- Registry Agent: Applies DS records to the parent zone and sends operation notifications.
Authorization Requirements:
- Cryptographically verifiable multi-hop delegation chain for a full audit trail.
- Fine-grained permission limited to a fixed set of domains, only allowing DS updating without modifying other DNS records.
- Support task-specific revocation: revoke all DS automation permissions without affecting other agent workflows.
- Standard audit context identifier passed across all agent hops for compliance logging.
Gap Analysis:
- What Works (Partially): Client Credentials can assign identities to registry/registrar agents. RFC 8693 token exchange supports simple single-hop agent delegation.
- **What's Missing (The Gap)
  - **Current DS automation does not use OAuth. OAuth only supports two-party delegation and lacks standard multi-hop RRR delegation syntax; proprietary JWT claims hurt interoperability.
  - **OAuth has no standardized task/bulk revocation. Securing DS automation via OAuth would require repetitive single-token revocation in incidents.
  - **No reserved OAuth JWT claim for cross-agent audit IDs, breaking consistent compliance logging for DS automation.

Use Case 9: Managed Services

Scenario Description: The managed service model refers to an integrated end-to-end managed service solution delivered by a prime service integrator through the aggregation of infrastructure and services from multiple sub-providers. End users interact with a single, unified resource platform instead of multiple separate sub-modules. However, coordinating resources across different administrative domains introduces complex authorization challenges.
Example:
- Telecom operator delivers a managed global secure SD-WAN orchestration service, which requires coordination of many localized regional telecom operators/ISPs and security service providers.
- Telecom operator delivers a managed smart home + security solution through a home-hub, which integrates controls over IPTV, streaming services, smart IoT (security cameras) etc.
Authorization Requirements:
- Cross-domain Authorization: The fast provisioning of an integrated service (take SD-WAN as an example) requires acquiring authorization from different service sub-providers in their respective administrative domains.
- Batched Authorization: The fast provisioning of the integrated service requires requesting a batch of authorizations from different service sub-providers.
- Delegated Authorization:
  - Prime service integrator may need to conditionally delegate network configuration modification privileges for specific branches to the on-site O&M teams of local sub-providers. This delegation MAY be hierarchical.
  - End-users are often times tenants that only have renting privileges instead of ownership rights. Thus technically the prime service integrator is delegating the access privileges to the end-user to access each modular sub-service.
Gap Analysis:
- What Works:
  - Cross-domain Single Authorization: The OAuth allows cross-domain authorization through OAuth 2.0 authorization grant and Identity Chaining. But it MUST require one access token at a time.
  - Single Domain Workflow: The OAuth allows workflow orchestration through Transaction Token. It only allows workflow inside one trust domain.
- What's Missing (The Gap):
  - Batched Authorization: How to request access permissions to a batch of resources from the user at once, while precisely delegating fine-grained privileges to the respective sub-agent responsible for executing each sub-task.
  - Cross-domain Workflow: How to request access permissions across different trust domains, while ensuring secure propagation of important contextual information (claims, caller identity, rich authorization contexts...).

Use Case 10: Cross-Organizational Delegation Between Fully-Provisioned Organizations

Scenario Description: An agent operated by Organization A must invoke a service operated by Organization B. Each organization runs its own complete trust infrastructure: its own authorization server, identity provider, and workload identity systems. No trust relationship, federation agreement, key exchange, or communication channel exists between them before the first request, and none can be assumed: the interaction may be first contact. This is the ordinary condition of open agent-to-tool ecosystems (e.g., MCP tool servers, agent-mediated commerce) once agents cross organizational boundaries.
Example: A manufacturer's procurement agent, acting on behalf of a named employee, invokes a supplier's quoting and ordering API. The supplier has never onboarded the manufacturer. At request time the supplier's service must determine: (a) that the calling agent is operated by an identifiable, accountable organization; (b) that the agent holds authority for this specific operation, delegated through possibly several intermediate agents, each of which may only have narrowed it; (c) that the agent acts on behalf of the claimed human principal; and (d) that none of that authority has been revoked - all within its normal request latency, and without a synchronous callback to the manufacturer's infrastructure, whose availability and reachability it does not control.
Authorization Requirements:
Stranger Verifiability: The receiving organization must be able to verify authority rooted in the sending organization using generally available infrastructure that both parties joined independently, with no interaction-specific bilateral arrangement (no pre-exchanged keys, no shared authorization server, no federation onboarding step).
Verifiable Attenuated Delegation: Presented authority may have passed through multiple agents. Each hop may only narrow it (permitted operations, resource scope, validity), and the receiver must be able to verify both the narrowing and the invariance of the on-behalf-of principal from the presented material itself, rather than by trusting the sending organization's internal policy.
Local Decision with Bounded Revocation Staleness: The receiver's authorization decision must complete without a runtime call to the sending organization, while revocation of the sender's authority must still reach the receiver with an explicit, bounded staleness that the receiver can enforce and fail safe on.
Gap Analysis:
- What's Missing (The Gap):
  - Pre-Established Trust Assumption: Existing cross-domain mechanisms presuppose arranged trust. OAuth Identity Chaining, for example, requires the participating authorization servers to have pre-established trust and exchanged key material (Section 2.1) - precisely what a first-contact interaction lacks by definition.
  - Runtime Coupling to Foreign Infrastructure: Token-exchange and challenge-based patterns place the sending side's authorization server (or one federated with it) in the request path, making the availability, latency, and reachability of another organization's infrastructure a precondition for the receiver's own service.
  - Delegation Opacity at the Receiver: Standard access tokens do not allow a receiving organization to independently verify multi-hop narrowing or the invariance of the acting-for principal across intermediaries; the receiver is asked to trust issuer-side policy it cannot inspect.

Category 3: Security & Administrative Scenarios

Use Case 11: Automated Security Incident Response

Scenario Description: A security agent detects a security threat and must take immediate, automated action to contain it.
Example: A security system detects that an employee's laptop has been compromised by malware. An automated security agent is triggered to:
1. Immediately revoke all active login sessions for that employee across all company applications (e.g., email, code repository, HR system).
2. Isolate the compromised laptop from the corporate network.
3. Temporarily suspend the user's account to prevent further unauthorized access.
Authorization Requirements:
- Privileged, System-Level Authority: The security agent needs broad, pre-approved authority to perform high-impact administrative actions.
- Global Token Revocation API: The agent must be able to make a single API call to the Authorization Server to "immediately revoke all access and refresh tokens associated with user ID employee-123."
- Non-Repudiable Execution Evidence: For post-hoc audits and security forensics, simply logging the action is insufficient. A critical requirement is the generation of durable, non-repudiable, and potentially offline-verifiable evidence at the moment of execution. This evidence must cryptographically attest to the specific action performed (e.g., "Agent sec-ops-bot-01 isolated host laptop-789 at 2024-08-21T10:00:00Z under policy POL-456 in response to alert ALERT-XYZ"). This formal proof is essential for accountability, especially when an automated agent takes high-risk actions like suspending a user account.
Gap Analysis:
- What Works (Partially): The OAuth Client Credentials grant is suitable for giving the security agent its own system-level identity and authority.
- What's Missing (The Gap):
  - Critically Inadequate Revocation API: This is the most significant gap for this use case. The one-token-at-a-time revocation endpoint in is completely insufficient for a security incident. The need to make potentially thousands of individual API calls to revoke tokens is too slow and unreliable during an active attack. The lack of a standardized bulk revocation API is a major operational and security failure point.
  - Absence of a Standard for Verifiable Action Records: The OAuth framework focuses on granting and validating the authority to perform an action (i.e., possessing a valid token). It does not, however, define a standard mechanism for creating a durable, cryptographically verifiable record of the action itself at the moment of execution. In a security context, a simple log entry stating "action performed" is insufficient for high-stakes forensic analysis. What is missing is a formal, non-repudiable piece of evidence that binds the agent's identity, the specific action taken (e.g., "isolate host laptop-789"), the policy justification, and the timestamp into a single, verifiable artifact. This gap makes it difficult to construct an undeniable audit trail for automated, high-risk security operations.

Analysis of Existing OAuth Extensions The OAuth 2.0 ecosystem is rich with extensions designed to address security and functionality gaps in the core specification. However, many of these powerful extensions were conceived before the rise of highly autonomous, dynamic, and often ephemeral AI agents. Their design assumptions, therefore, do not always align with the unique challenges presented by agent-centric architectures. This section analyzes several key existing extensions and related concepts to evaluate their applicability to agent authorization use cases. For each, we identify its strengths, its limitations in agentic scenarios, and potential directions for evolution.

Rich Authorization Requests (RAR)

Applicability and Strengths: RAR represents a significant step beyond simple string-based scopes. It allows clients to request fine-grained, structured, and parameterized permissions. For example, instead of a generic transaction scope, a client can request authorization for a specific action like {"type": "payment", "amount": "50", "currency": "USD", "recipient": "X"}. This capability is invaluable for creating auditable and least-privilege grants, which is a core requirement for reining in agent capabilities.
Limitations in Agentic Scenarios: The primary limitation of RAR in agentic scenarios is its static nature. RAR defines the structure of a permission, but it assumes the values are known at the time of the authorization request. Autonomous agents often operate with non-deterministic logic; they discover the need for specific actions as they execute a task. An agent planning a picnic might not know the exact cost or booking details for a park shelter until it has already completed several other steps. This makes it difficult to request all necessary, fine-grained permissions upfront. In essence, RAR is a powerful Grant-Layer mechanism for defining the shape of authority. It cannot, by design, capture the user's specific, just-in-time consent for a transaction whose final parameters were only determined at the moment of execution. It describes the authority, not the human decision at runtime.
Potential Directions for Evolution: A potential direction is to evolve RAR or develop a complementary mechanism for "bounded capabilities". This would allow a user to grant an agent a budget or a set of constraints (e.g., "a maximum of $100 for picnic supplies within a 10-mile radius"). The agent could then use this grant to dynamically construct and justify specific RAR-formatted requests at runtime, with the authorization server validating each request against the pre-approved bounds.

Demonstrating Proof-of-Possession (DPoP) [RFC9449]

Applicability and Strengths: DPoP enhances security by cryptographically binding access tokens to a specific client's public/private key pair. This effectively prevents token theft and replay attacks, as a stolen token is useless without the corresponding private key. This is a critical security baseline for any system where agents handle sensitive operations.
Limitations in Agentic Scenarios: The challenge arises in highly dynamic agent architectures. DPoP's model assumes a relatively stable client with a persistent key. This assumption breaks down when a primary agent needs to delegate a task to a dynamically created, ephemeral sub-agent, or when an agent migrates between compute environments. Each new instance would require a new token bound to its new key, creating significant overhead and complexity if it requires a full round-trip to the authorization server. DPoP is a critical Grant-Layer security control, binding a token to a client to prove the legitimacy of the actor possessing the authority. However, it says nothing about the legitimacy of the specific action being performed at the Execution Layer or the user's explicit consent for that action.
Potential Directions for Evolution: Future work could explore a "multi-hop DPoP" model. In this model, a parent agent holding a DPoP-bound token could securely derive a new, more constrained token for a sub-agent, binding it to the sub-agent's ephemeral key. This would create a verifiable chain of possession and delegation without requiring constant interaction with the central authorization server, making it more suitable for chained or group agent tasks.

Client-ID Metadata Document (CIMD) [draft-ietf-oauth-client-metadata]

Applicability and Strengths: CIMD (and the broader concept of dynamic client registration) proposes a powerful shift from static, pre-registered clients to dynamic, discoverable ones. By defining client_id as a resolvable URI, an Authorization Server can fetch client metadata on-the-fly. This enables "plug-and-play" onboarding for new agents and greatly simplifies the lifecycle management of cryptographic keys by exposing them via a jwks_uri.
Limitations in Agentic Scenarios: Despite its flexibility, CIMD's current metadata vocabulary is client-application-centric, not agent-centric.
1. Lack of Agent Context: Standard fields (e.g., redirect_uris, client_name) fail to describe agent-specific attributes like its level of autonomy, risk profile, or operational policies.
2. Public URI Dependency: The reliance on a stable, public URI is problematic for ephemeral or internal sub-agents that may not have a persistent, publicly resolvable address.
3. Missing Delegation Traceability: While CIMD can verify an agent's identity, it does not provide a standard mechanism to describe its lineage or delegation path (i.e., "who created this agent?").
Potential Directions for Evolution: To bridge these gaps, CIMD could be extended with:
1. Agent-Specific Metadata: Introduce new fields like agent_type, max_autonomous_budget, or human_in_the_loop_policy to enable better risk assessment by Authorization Servers.
2. Inline or Vouched-For Metadata: Allow ephemeral agents to present their metadata directly in a request or have it "vouched for" and signed by a trusted parent agent, removing the public URI requirement.
3. Trust Chain Assertions: Incorporate fields like parent_agent_id or integrate concepts from specifications like OpenID Federation to build a verifiable delegation chain.

Transaction Tokens

Applicability and Strengths: This refers to a common architectural pattern, often implemented using JWTs, where initial user context is encoded into a token and propagated through a series of internal microservices. This ensures consistent authorization and context within a trusted security domain.
Limitations in Agentic Scenarios: The fundamental gap is one of trust boundaries. This pattern is designed for use within a single, trusted system. It is ill-suited for multi-hop delegation scenarios involving untrusted third-party agents, as the tokens lack standard mechanisms for permission attenuation (reduction) or enforcement across organizational boundaries.
Potential Directions for Evolution: To be viable in agent ecosystems, this concept would need to evolve into a standardized "Attenuating Agent Token". Such a token would need a formal, interoperable mechanism for a parent agent to reduce permissions before passing it to a child agent, ensuring the child cannot exceed the parent's authority. Furthermore, embedding verifiable proofs of execution could enhance end-to-end auditability.