Network Working Group Y. Ni Internet-Draft C. P. Liu Intended status: Informational Huawei Expires: 1 January 2027 30 June 2026 Batch Authorization Delegation draft-ni-batch-authorization-delegation-00 Abstract This document describes a mechanism for Batch Authorization Delegation, which enables a batch of fine-grained, actor-bound permissions in a single request and securely delegates them to multiple collaborating actors. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://NiYuan224.github.io/draft-ni-batch-authorization-delegation/ draft-ni-batch-authorization-delegation.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- ni-batch-authorization-delegation/. Source for this draft and an issue tracker can be found at https://github.com/NiYuan224/draft-ni-batch-authorization-delegation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 January 2027. Ni & Liu Expires 1 January 2027 [Page 1] Internet-Draft Batch Authorization Delegation June 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Batch Authorization Delegation . . . . . . . . . . . . . . . 6 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Batch Token . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. RAR Extension with the may_act field . . . . . . . . 8 3.2.2. Requesting and Issuing a Batch Token . . . . . . . . 10 3.2.3. Batch Token Claims . . . . . . . . . . . . . . . . . 11 3.3. Downscoped Token . . . . . . . . . . . . . . . . . . . . 12 3.3.1. Token Exchange Request . . . . . . . . . . . . . . . 12 3.3.2. Processing Rules of the Authorization Server . . . . 14 3.3.3. Downscoped Token Claims . . . . . . . . . . . . . . . 14 4. Derivative Scenarios . . . . . . . . . . . . . . . . . . . . 15 4.1. Single-Domain Batch Authorization Delegation . . . . . . 15 4.2. Batch Authorization Delegation with Cross-Domain Sub-Clients . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Workflow . . . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Batch Authorization Delegation with the Cross-Domain User . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.4. Combined Cross-Domain Scenario . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Normative References . . . . . . . . . . . . . . . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . 21 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Ni & Liu Expires 1 January 2027 [Page 2] Internet-Draft Batch Authorization Delegation June 2026 1. Introduction Due to the rise of collaborative service ecosystems and AI Agents, resource access patterns are shifting from a traditional, linear, single client-server model to complex multi-entity orchestration. A task may consists of a batch of sub-tasks, which may require authorizations to different resources. Although a human user can request authorization for each resource, this work is usually carried out by a principal personal assistant AI Agent. While authorizing total privileges to the personal assistant agent is doable, it risks granting excessive privileges to it, thus oppose to the minimal privilege principle. On the other hand, if the principal agent request human authorization for every resource, it will reduce automated efficiency. Therefore, the core challenge is 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. Certain use cases include: *(1) China UnionPay APOP (Agentic Payment Open Protocol) Framework:* A central agent from China UnionPay coordinates with multiple bank- specific sub-agents to calculate the best user discounts. The central agent requests a one-time batch authorization for all linked accounts from the user, and precisely delegates privileges so that each sub-agent only receives query and payment access for its respective bank. This strictly preventa one bank from leaking or spying on another bank's account existence, financial balances, or transaction histories. *(2) Office Agent Orchestration:* An office agent coordinates the generation of a market insight report slide by deploying three specialized sub-agents in parallel based on a one-time batch approval from the user. It strictly delegates privileges to each sub-agent: the finance sub-agent is granted access to internal financial records, the internet search sub-agent is completely barred from seeing any intranet data to prevent confidential leaks during web queries, and the slide generator sub-agent is authorized to generate and save the final presentation using the aggregated outputs. Without batch authorization, the workflow would stall whenever a sub- agent reaches its specific sub-task and attempts to request its required permission, such as fetching external web resources or requesting file-write permissions. Asynchronously prompting the user for these consents would inevitably cause task blockages and ruin the automated multi-agent experience, which is unacceptable. Ni & Liu Expires 1 January 2027 [Page 3] Internet-Draft Batch Authorization Delegation June 2026 While the existing OAuth 2.0 protocol and its extensions provide a foundation for authorization, they lack native support for efficient, secure delegation for a batch of coordinated tasks: *(1) OAuth 2.0[RFC6749]:* The OAuth 2.0 authorization framework enables a client to obtain limited access to protected resources on behalf of a resource owner. However, in a multi-entity collaboration scenario, this requires each entity to independently initiate its own authorization flow. This results in multiple user interactions, introducing significant end-to-end latency and severe user fatigue. *(2) OAuth 2.0 Token Exchange[RFC8693]:* Token Exchange defines a delegation mechanism and introduces the may_act claim to authorize an actor to act on behalf of a subject. However, the may_act claim only determines who is authorized to act. It does not provide a way to link or specify which subset of permissions are being delegated to this actor. *(3) OAuth 2.0 Rich Authorization Request (RAR) [RFC9396]:* RAR introduces a new parameter authorization_details to allow clients to express their fine-grained authorization requirements using the JSON structures. Such a parameter allows several fine-grained permissions to be included in a single authorization request, as well as the issued access token. However, RAR does not currently specify how these structured permissions can be partitioned and delegated to different actors during a subsequent token exchange. In summary, the existing OAuth 2.0 protocol and its extensions lack a mechanism to express, partition, and delegate fine-grained structured permissions across multiple collaborating entities. To bridge this gap, this document adds the delegation information directly to the multiple fine-grained permissions in the RAR. By extending the authorization_details with a may_act field, a client can request a comprehensive set of permissions, each of which specify which actor is authorized to exercise such privilege. The Authorization Server (AS) then responds this request with a Batch Token, which contains the above permissions and their corresponding designated actors. When an actor performs a token exchange using the Batch Token, the AS applies a downscoping strategy, filtering the permissions based on the consistency of the may_act field and actor's identity. This ensures a convenient authorization experience for the user while strictly enforcing the principle of minimal privilege across multiple collaborating entities. Ni & Liu Expires 1 January 2027 [Page 4] Internet-Draft Batch Authorization Delegation June 2026 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses common OAuth and token processing terms such as "access token", "authorization server" (AS), "resource server" (RS), "authorization request", "access token response" defined by [RFC6749], "Trust Domain", "JWT Authorization Grant" defined by [I-D.ietf-oauth-identity-chaining], "identity assertion" defined by [I-D.ietf-oauth-identity-assertion-authz-grant]. In addition, the following terms are defined for this document: Leader-Client: The entity responsible for coordinating tasks and requesting permissions in a batch on behalf of Sub-Clients. The Leader-Client initiates rich authorization requests to the AS, and sends the obtained Batch Token to Sub-Clients. According to examples listed above, Leader-Client is the principal personal assistant agent, a microservice orchestrator, or an API gateway. Sub-Client: The entity that is subordinate to the Leader-Client and redeem access tokens to Resource Servers (RS) to perform specific sub-tasks. The Sub-Client exchanges the received Batch Token for a downscoped access token with partial privileges. Sub-clients could be sub-agents and microservices. Batch Authorization Delegation: A mechanism proposed in this document that a Leader-Client requests permissions in a batch and delegates them to its subordinate Sub-Clients. Authorization Item: An authorization item defines one permission per one corresponding designated actor. There may be multiple Authorization Items within one authorization_details, which is later encapsulated in the rich authorization request and the issued Batch Token. Batch Token: A special JWT access token issued by the AS to the Leader-Client. It encapsulates multiple Authorization Items, enabling subsequent delegation. Designated Actor: The may_act field within an authorization item that specifies the Sub-Client authorized to exercise that permission. Ni & Liu Expires 1 January 2027 [Page 5] Internet-Draft Batch Authorization Delegation June 2026 Downscoped Token: The access token issued to a Sub-Client as a result of token exchange, which is to be used at the RS to access protected resources. It contains only a subset of authorization items whose designated actors match the requesting Sub-Client's identity. 3. Batch Authorization Delegation This document specifies a mechanism combining OAuth RAR [RFC9396] and Token Exchange [RFC8693] to achieve Batch Authorization Delegation. The Leader-Client sends a rich authorization request with multiple authorization items to the AS. Each authorization item not only describes the required permission but also declares the Sub-Client to which the permission can be delegated to via designated actors. Upon user confirmation, the AS issues a Batch Token to the Leader-Client, which encapsulates the authorization items confirmed by the user. The Leader-Client distributes the Batch Token to Sub-Clients. The Sub-Client initiates a token exchange request to the AS. The AS verifies the Sub-Client's identity against the Designated Actors in the Batch Token, and then filters out one or more authorization items corresponding to this specific Sub-Client. Then the AS generates a Downscoped Token containing only the permissions from the filtered authorization items. Such a mechanism enables the Leader-Client to perform a one-time batch authorization as well as ensuring each Sub-Client obtains an access token containing only the permissions it requires, thereby realizing both efficiency and security. 3.1. Overview Figure 1 shows the flow of Batch Authorization Delegation. Note that a Leader-Client MAY coordinate several Sub-Clients. For simplicity, only one Sub-Client is shown in Figure 1. Ni & Liu Expires 1 January 2027 [Page 6] Internet-Draft Batch Authorization Delegation June 2026 +----++-------------+ +----+ +----------++----+ |User||Leader-Client| | AS | |Sub-Client|| RS | +-+--++------+------+ +--+-+ +-----+----++--+-+ | |(1)RAR | | | | |(with may_act)| | | | +--------------> | | | |(2)Ask for | | | | | consent | | | <----------+--------------+ | | |(3)Consent| | | | +----------+--------------> | | | |(4)Issue | | | | | Batch Token | | | | <--------------+ | | | |(5)Distribute | | | | | Batch Token | | | | |--------------+--------------> | | | |(6)Token | | | | | exchange | | | | | request | | | | <--------------+ | | | | | | | | | | | | | |(7)Verify | | | | +-+ identity | | | | | | &Downscope | | | | <-+ | | | | |(8)Downscoped | | | | | Token | | | | +--------------> | | | | |(9)Access | | | |--------> | | | | | _Figure 1: Batch Authorization Delegation Flow_ (1) The Leader-Client sends a rich authorization request containing multiple authorization items to the AS. Each authorization item includes a fine-grained permission (described by several fields defined in [RFC9396], e.g., type, actions, locations, etc.) and a designated actor that uses the may_act field. to designate which Sub- Client is authorized for the permission. (2) After receiving the rich authorization request, the AS presents all authorization items in the request to the user for consent. (3) The user confirms all or some of the authorization items and sends the result back to the AS. Ni & Liu Expires 1 January 2027 [Page 7] Internet-Draft Batch Authorization Delegation June 2026 (4) The AS generates a Batch Token, which encapsulates the authorization items confirmed by the user and issues it to the Leader-Client. (5) The Leader-Client distributes the Batch Token to the Sub-Client. (6) The Sub-Client initiates a token exchange request to the AS to exchange the Batch Token to a Downscoped Token. (7) The AS verifies the identity of Sub-Client against the designated actors in the Batch Token to filter the authorization items corresponding to the Sub-Client. (8) The AS generates a Downscoped Token that only contains the permissions in the filtered authorization items and send it to the Sub-Client. (9) The Sub-Client accesses the RS with the Downscoped Token. This mechanism offers two key advantages. * First, it fully reuses existing standards, combining RAR's flexible permission definitions with Token Exchange's delegation semantics by simply moving the may_act claim from the entity level down to individual authorization items without altering its original meaning. This slight change effectively fulfills the expression, partition, and delegation purpose of fine-grained structured permissions across multiple collaborating entities. * Second, the final Downscoped Token introduces no new claims or structural changes. Since RS deployments are often numerous and costly to upgrade, this design ensures zero modification to existing RSs, enabling smooth adoption with minimal reconfiguration. 3.2. Batch Token 3.2.1. RAR Extension with the may_act field In [RFC8693], the may_act is a top-level claim, which makes a statement of one party is authorized to become the actor and act on behalf of another party. It is an entity-level delegation, without further distinguishing the permission subsets. Ni & Liu Expires 1 January 2027 [Page 8] Internet-Draft Batch Authorization Delegation June 2026 In contrast, this document leverages authorization_details defined in [RFC9396] to describe multiple authorization items, each of which contains a permission and a nested may_act field serving as a designated actor. This helps to define who is authorized to perform which permission, thus changing the entity-level delegation into an item-level delegation. *may_act* *REQUIRED.* A JSON object that identifies the specific Sub-Client authorized to exercise the permission. The may_act JSON object contains fields that specify the intended actor for a particular authorization item. This document defines the following two fields: *sub* *REQUIRED.* A string that uniquely identifies the Sub-Client authorized to exercise the permission. *aud* *OPTIONAL.* A string that identifies the AS of the trust domain where the Sub-Client resides. If the Sub-Client and the Leader-Client are located in different Trust Domains, this field MUST be present to specify the target AS. If this field is omitted, it MUST be assumed that the Sub-Client and the Leader-Client reside in the same trust domain. Figure 2 shows an example of authorization_details containing the may_act field. It represents a typical travel management scenario in which the Leader-Client requests two distinct authorization items: a flight booking permission delegated to the Flight-Agent, and a hotel reservation permission delegated to the Hotel-Agent. Both Sub- Clients are located in the same trust domain as the Leader-Client so that the may_act.aud field is omitted. This structure demonstrates how multiple permissions can be bound to different actors within a single authorization request. Ni & Liu Expires 1 January 2027 [Page 9] Internet-Draft Batch Authorization Delegation June 2026 [ { "type": "flight_booking", "actions": ["search", "book"], "locations": ["https://example.com/flights"], "may_act": { "sub": "flight_agent@example.com" } }, { "type": "hotel_reservation", "actions": ["search", "book"], "locations": ["https://example.com/hotels"], "may_act": { "sub": "hotel_agent@example.com" } } ] _Figure 2: authorization_details with the may_act field_ 3.2.2. Requesting and Issuing a Batch Token The lead-client sends an authorization request that contains authorization_details with may_act fields to the AS. The AS MUST ask the user for consent to the requested authorization items. The general processing rules of the AS defined in [RFC9396] apply, with the following extensions: * The AS MUST validate that the Sub-Client identified in the may_act.sub field is known. If the may_act.aud field is present, the AS MUST validate that the target AS is reachable and trusted according to local policies. * The AS MUST present all the authorization items, including the requested permissions and their corresponding intended Sub-Clients to the user. The user MAY: - Grant all requested authorization items. - Grant only a subset of the authorization items. * The AS MUST record the consented authorization items, including the may_act fields, as part of a grant (e.g., the authorization code). Ni & Liu Expires 1 January 2027 [Page 10] Internet-Draft Batch Authorization Delegation June 2026 After user consent, the AS issues an authorization code as a grant to the Leader-Client. The Leader-Client then exchanges the authorization code for a Batch Token, following the standard authorization response and token request flow as defined in [RFC6749]. Subsequently, the AS generates a Batch Token and returns it to the Leader-Client in the Token response. The Batch Token is a JWT access token conforming to [RFC9068], with the following claims and values. 3.2.3. Batch Token Claims *iss* *REQUIRED.* The identifier of the AS. *sub* *REQUIRED.* The identifier of the user who grants the consent. *aud* *REQUIRED.* MUST be set to the AS itself, as the Batch Token is intended only for token exchange at the AS and cannot be directly used at the RS. *client_id* *REQUIRED.* The identifier of the Leader-Client that initiated the authorization request. *authorization_details* *REQUIRED.* An JSON array containing all the consented authorization items, including the permission descriptions and their corresponding may_act Designated Actors. Figure 3 shows an example of the Batch Token JWT payload, which encapsulates all consented authorization items from Figure 2. The sub claim identifies the user who consents, the client_id claim identifies the travel assistant as the Leader-Client that initiates the request, each may_act.sub field identifies the Sub-Client authorized to exercise the corresponding permission. The aud claim is set to the AS itself, as the Batch Token will be presented back to the AS for further token exchange. Ni & Liu Expires 1 January 2027 [Page 11] Internet-Draft Batch Authorization Delegation June 2026 { "iss": "https://as.example.com", "sub": "user@example.com", "aud": "https://as.example.com", "client_id": "travel_assistant@example.com", "exp": 1777881600, "iat": 1777795200, "jti": "batch-token-8b4729cc-32e4-4370-8cf0-5796154d1296", "authorization_details": [ { "type": "flight_booking", "actions": ["search", "book"], "locations": ["https://example.com/flights"], "may_act": { "sub": "flight_agent@example.com" } }, { "type": "hotel_reservation", "actions": ["search", "book"], "locations": ["https://example.com/hotels"], "may_act": { "sub": "hotel_agent@example.com" } } ] } _Figure 3: Batch Token JWT Payload_ 3.3. Downscoped Token 3.3.1. Token Exchange Request When a Sub-Client receives a Batch Token from the Leader-Client, it MUST perform a token exchange request to the AS to obtain a Downscoped Token. The Batch Token MUST NOT be used directly to the RS to redeem resources by anyone. Within the token exchange request, the parameters described in section 2.1 of [RFC8693] apply with the following additional requirements: *resource* *OPTIONAL.* The URI of the target RS where the Sub-Client intends to use the Downscoped Token. *audience* *OPTIONAL.* The well-known/logical name of the target RS where the Sub-Client intends to use the Downscoped Token. Ni & Liu Expires 1 January 2027 [Page 12] Internet-Draft Batch Authorization Delegation June 2026 *subject_token* *REQUIRED.* The Batch Token received from the Leader-Client. *subject_token_type* *REQUIRED.* urn:ietf:params:oauth:token-type:jwt. Since the AS has to identify the requesting Sub-Client to filter the authorization items, it MUST authenticate the Sub-Client. The AS MAY use the following authentication methods: * Password-based authentication as defined in Section 2.3.1 of [RFC6749]. * Bearer JWT-based authentication as defined in [RFC7523]. * WIMSE-based authentication methods, as defined in [I-D.ietf-wimse-wpt], [I-D.ietf-wimse-http-signature], and [I-D.ietf-wimse-mutual-tls]. * Actor token as defined in [RFC8693]. Figure 4 shows a token exchange request initiated by the Flight- Agent. In this request, the Flight-Agent provides the received Batch Token from Figure 3 as the subject_token. To satisfy the requirement for client authentication, the Flight-Agent provides its own identity token as an actor_token. POST /as/token.oauth2 HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange &subject_token= &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt &actor_token=eyJhb... &actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt _Figure 4: Token Exchange Request_ The claims of the actor_token are detailed in Figure 5. { "aud":"https://as.example.com", "iss":"https://original-issuer.example.net", "exp": 1778400000, "sub":"flight_agent@example.net" } Ni & Liu Expires 1 January 2027 [Page 13] Internet-Draft Batch Authorization Delegation June 2026 _Figure 5: Actor Token Claims_ 3.3.2. Processing Rules of the Authorization Server In addition to authenticating the requesting Sub-Client, the AS MUST * Validate the Batch Token provided in the subject_token. * Retrieve the authorization_details from the Batch Token's payload and filter only those authorization items whose may_act.sub fields exactly matches the authenticated Sub-Client's identity. 3.3.3. Downscoped Token Claims The AS generates a Downscoped Token that only contains the permissions in the filtered authorization items. The format of this token MAY be a JWT access token conforming to [RFC9068] or any other format at the AS's discretion. If a JWT Downscoped Token is used, the following constraints on its claim values apply: *sub* *REQUIRED.* The owner who grants the consent (copied from the sub claim of the Batch Token in the subject_token parameter). *client_id* *REQUIRED.* The identifier of the authenticated sub-client. *aud* *OPTIONAL.* The target RS where the Sub-Client intends to use the Downscoped Token. *authorization_details* *OPTIONAL.* A JSON array containing the permissions from the filtered authorization items. Since the may_act field has already been enforced as a designated actor by the AS during token exchange, it MAY be omitted in the Downscoped Token. Figure 6 shows a Downscoped Token issued to the Flight-Agent after token exchange. Its sub claim identifies the end-user who grants the consent, its aud claim points directly to target service (https://example.com/flights), and the client_id identifies the Flight-Agent. The authorization_details array contains only the flight-booking permission, with the may_act field removed. Ni & Liu Expires 1 January 2027 [Page 14] Internet-Draft Batch Authorization Delegation June 2026 { "iss": "https://as.example.com", "sub": "user@example.com", "aud": "https://example.com/flights", "client_id": "flight_agent@example.com", "exp": 1777881600, "iat": 1777795210, "jti": "downscoped-token-7c8d9a2e-4b12-4a3f-8e6c-2f9a8b3c7d5e", "authorization_details": [ { "type": "flight_booking", "actions": ["search", "book"], "locations": ["https://example.com/flights"], } ] } _Figure 6: Downscoped Token Payload_ 4. Derivative Scenarios Until now, the main procedures of the Batch Authorization Delegation is done. There are some more derivative scenarios with detailed additional steps and considerations, including: * Single-Domain Batch Authorization Delegation: The user, Leader- Client, and Sub-Clients all reside within the same trust domain managed by a single AS. * Batch Authorization Delegation with Cross-Domain Sub-Clients: The user and Leader-Client belong to the same trust domain, but Sub- Clients reside in one or more other trust domains, each managed by its own AS. * Batch Authorization Delegation with a Cross-Domain User: The Leader-Client and Sub-Clients belong to the same trust domain, while the user resides in another trust domain, each managed by its own AS. * Combined Cross-Domain Scenario: The user, Leader-Client, and Sub- Clients each reside in different trust domains, each managed by its own AS. 4.1. Single-Domain Batch Authorization Delegation In this case, the workflow and the examples are already given in Section 3 Figures. 1-6. Ni & Liu Expires 1 January 2027 [Page 15] Internet-Draft Batch Authorization Delegation June 2026 4.2. Batch Authorization Delegation with Cross-Domain Sub-Clients 4.2.1. Workflow The workflow in this case is a combination of Batch Authorization Delegation and identity chaining [I-D.ietf-oauth-identity-chaining]. Since the Sub-Client and Leader-Client reside in different trust domains, the Leader-Client in Domain A requests JWT Authorization Grants (JAGs) from the AS in Domain A via token exchange. The AS in Domain A inspects both the may_act.aud and may_act.sub fields within the Batch Token, filters and splits the authorization items to generates an actor-specific JAG for each designated Sub-Client. Taking the Sub-Client in Domain B as an example, the Leader-Client then presents the corresponding JAG as an assertion to the AS in Domain B to obtain an access token, which is subsequently exchanged by the specific Sub-Client in Domain B for a final Downscoped Token. This token exchange ensures that the final Downscoped Token is bound to the Sub-Client's own identity and contains only the specific permissions it required. Ni & Liu Expires 1 January 2027 [Page 16] Internet-Draft Batch Authorization Delegation June 2026 +--------++-------------+ +--------++--------+ +----------+ +--------+ | User ||Leader-Client| | AS || AS | |Sub-Client| | RS | |Domain A|| Domain A | |Domain A||Domain B| | Domain B | |Domain B| +---+----++------+------+ +-----+--++---+----+ +-----+----+ +---+----+ | |(1)RAR | | | | | |(with may_act) | | | | | +---------------> | | | | |(2)Ask for | | | | | | consent | | | | <------------+---------------+ | | | |(3)Consent | | | | | +------------+---------------> | | | | |(4)Issue | | | | | | Batch Token | | | | | <---------------+ | | | | |(a)Token | | | | | | exchange | | | | | | request | | | | | |---------------> | | | | |(b)Verify | | | | | | &Downscope | | | | | | +-+ | | | | | | | | | | | |(c)JAGs +-> | | | | <---------------+ | | | | |(d)JAG | | | | | +---------------+-------> | | | |(e)Access Token| | | | | <---------------+-------+ | | | |(f)Access Token| | | | | +---------------+-------+------------> | | | | |(6)Token | | | | | | exchange | | | | | | Request | | | | | <------------| | | | | |(8)Downscope| | | | | | Token | | | | | +------------> | | | | | |(9)access | | | | | +----------> | | | | | | _Figure 7: Batch Authorization Delegation with Cross-Domain Sub- Clients_ Steps (1)-(4) are the same as in Figure 1. Ni & Liu Expires 1 January 2027 [Page 17] Internet-Draft Batch Authorization Delegation June 2026 (a) The Leader-Client in Domain A exchanges the Batch Token with the AS in Domain A for actor-specific JAGs that can be used in the AS in Domain B. (b) The AS of Domain A inspects the may_act fields within the Batch Token, filtering and splitting the authorization items down to each target actor in Domain B. (c) The AS of Domain A issues actor-specific JAGs, with the nested may_act field in the authorization_details removed. This step requires trust relationship between the ASs in Domain A and Domain B. See Section 2.1 of [I-D.ietf-oauth-identity-chaining] for the trust relationship establishment. (d) The Leader-Client in Domain A presents the JAG for the specific Sub-Client as an assertion to the AS of Domain B. (e) The AS of Domain B validates the JAG, extracts and encapsulates the filtered authorization items in an access token and sends it to the Leader-Client. (f) The Leader-Client sends the access token to the Sub-Client. Steps (6)-(9) are the same as in Figure 1. By splitting and filtering batch tokens entirely within the Domain A, the key advantage of the above mechanism is the AS of Domain B is relieved from handling complex batch authorization processing. This minimizes upgrade overhead for downstream ASs, ensuring rapid and seamless compatibility with existing cross-domain OAuth deployments. 4.2.2. Examples The following shows some typical examples in the workflow of Figure 7, which is correspond to the use case (1) in Section 1. 4.2.2.1. Batch Token Figure 8 illustrates a Batch Token payload issued by a leading Chinese Financial Alliance's AS in step (4). The Batch Token contains two authorization items: one for searching and calculating max availble coupons at Bank_A (benefit_agent), and another for the same actions at Bank_B. The may_act.aud field specifies the AS location, while the may_act.sub field specifies the designated actor. Ni & Liu Expires 1 January 2027 [Page 18] Internet-Draft Batch Authorization Delegation June 2026 { "iss": "https://as.alliance.example.com", "sub": "user@alliance.example.com", "aud": "https://as.alliance.example.com", "client_id": "finance_assistant@alliance.example.com", "exp": 1777881600, "iat": 1777795200, "jti": "4a7b203c-e591-4916-b8df-d2b389f4621c", "authorization_details": [ { "type": "benefit_bank_a", "actions": ["search", "calculate"], "locations": ["https://bank_a.example.com/benefits"], "may_act": { "sub": "benefit_agent@bank_a.example.com", "aud": "https://as.bank_a.example.com" } }, { "type": "benefit_bank_b", "actions": ["search", "calculate"], "locations": ["https://bank_b.example.com/benefits"], "may_act": { "sub": "benefit_agent@bank_b.example.com", "aud": "https://as.bank_b.example.com" } } ] } _Figure 8: Batch Token Payload_ 4.2.2.2. JWT Authorization Grant Figure 9 shows the JAG payload issued by the Finance Alliance AS in step (c), specifically filtered for Bank_A's benefit_agent. In accordance with step (b), the Finance Alliance AS inspects the may_act fields of the Batch Token (Figure 8), extracts and encapsulates the benefit_bank_a item into the JAG, with the may_act field removed. Ni & Liu Expires 1 January 2027 [Page 19] Internet-Draft Batch Authorization Delegation June 2026 { "iss": "https://as.alliance.example.com", "sub": "user@alliance.example.com", "aud": "https://as.bank_a.example.com", "client_id": "finance_assistant@alliance.example.com", "iat": 1777795210, "exp": 1777795300, "authorization_details": [ { "type": "benefit_bank_a", "actions": ["search", "calculate"], "locations": ["https://bank_a.example.com/benefits"], } ] } _Figure 9: JAG Payload_ The subsequent formats of the access token, token exchange requests, and downscoped tokens fully reuse the standard profiles defined in Section 3 of [I-D.ietf-oauth-identity-chaining], and are therefore omitted here. 4.3. Batch Authorization Delegation with the Cross-Domain User When the user resides in a different trust domain from the clients, one potential approach is to explore the combination of batch authorization delegation and identity assertion [I-D.ietf-oauth-identity-assertion-authz-grant]. The user's client could obtain an Identity Assertion from its local IdP, exchange it for an Identity Assertion JWT Authorization Grant (ID-JAG) targeting the AS of the leader-client's domain, and then exchange it into an access token for the Leader-Client; the Leader-Client might then exchange this access token to a batch token. Because this pattern introduces the delegation of user's intent, the specific workflow require further analysis and are open for working group discussion. 4.4. Combined Cross-Domain Scenario In some deployments, the user, the leader-client, and the sub-clients may each reside in different trust domains. A combination of the workflows defined in Sections 4.2 and 4.3 directly supports this scenario. 5. Security Considerations TODO Security Ni & Liu Expires 1 January 2027 [Page 20] Internet-Draft Batch Authorization Delegation June 2026 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . 7.2. Informative References Ni & Liu Expires 1 January 2027 [Page 21] Internet-Draft Batch Authorization Delegation June 2026 [I-D.ietf-oauth-identity-assertion-authz-grant] Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz- grant-04, 21 May 2026, . [I-D.ietf-oauth-identity-chaining] Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-16, 26 June 2026, . [I-D.ietf-wimse-http-signature] Salowey, J. A. and Y. Sheffer, "WIMSE Workload-to-Workload Authentication with HTTP Signatures", Work in Progress, Internet-Draft, draft-ietf-wimse-http-signature-03, 7 April 2026, . [I-D.ietf-wimse-mutual-tls] Salowey, J. A. and Y. Rosomakho, "Workload Authentication Using Mutual TLS", Work in Progress, Internet-Draft, draft-ietf-wimse-mutual-tls-01, 5 May 2026, . [I-D.ietf-wimse-wpt] Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof Token", Work in Progress, Internet-Draft, draft-ietf- wimse-wpt-01, 2 March 2026, . Acknowledgments TODO acknowledge. Authors' Addresses Yuan Ni Huawei Email: niyuan1@huawei.com Ni & Liu Expires 1 January 2027 [Page 22] Internet-Draft Batch Authorization Delegation June 2026 Chunchi Peter Liu Huawei Email: liuchunchi@huawei.com Ni & Liu Expires 1 January 2027 [Page 23]