Batch Authorization Delegation
draft-ni-oauth-batch-authorization-delegation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ni Yuan , Peter Chunchi Liu | ||
| Last updated | 2026-07-06 (Latest revision 2026-07-03) | ||
| Replaces | draft-ni-batch-authorization-delegation | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ni-oauth-batch-authorization-delegation-00
Network Working Group Y. Ni
Internet-Draft C. P. Liu
Intended status: Informational Huawei
Expires: 4 January 2027 3 July 2026
Batch Authorization Delegation
draft-ni-oauth-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-oauth-batch-authorization-
delegation/draft-ni-oauth-batch-authorization-delegation.html.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ni-oauth-batch-authorization-
delegation/.
Source for this draft and an issue tracker can be found at
https://github.com/NiYuan224/draft-ni-oauth-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 4 January 2027.
Ni & Liu Expires 4 January 2027 [Page 1]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 2]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 3]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 4]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 5]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 6]
Internet-Draft Batch Authorization Delegation July 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 | |
| | <--------------+ |
| | | <Batch Token>| |
| | | | |
| | |(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 4 January 2027 [Page 7]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 8]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 9]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 10]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 11]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 12]
Internet-Draft Batch Authorization Delegation July 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=<Encoded Batch 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 4 January 2027 [Page 13]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 14]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 15]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 16]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 17]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 18]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 19]
Internet-Draft Batch Authorization Delegation July 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 4 January 2027 [Page 20]
Internet-Draft Batch Authorization Delegation July 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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[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, <https://www.rfc-editor.org/rfc/rfc7523>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
2021, <https://www.rfc-editor.org/rfc/rfc9068>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/rfc/rfc9396>.
7.2. Informative References
Ni & Liu Expires 4 January 2027 [Page 21]
Internet-Draft Batch Authorization Delegation July 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,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
identity-assertion-authz-grant-04>.
[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, <https://datatracker.ietf.org/doc/html/draft-
ietf-oauth-identity-chaining-16>.
[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, <https://datatracker.ietf.org/doc/html/draft-
ietf-wimse-http-signature-03>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
mutual-tls-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
wpt-01>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Yuan Ni
Huawei
Email: niyuan1@huawei.com
Ni & Liu Expires 4 January 2027 [Page 22]
Internet-Draft Batch Authorization Delegation July 2026
Chunchi Peter Liu
Huawei
Email: liuchunchi@huawei.com
Ni & Liu Expires 4 January 2027 [Page 23]