Web Authorization Protocol Working Group Z. Du Internet-Draft China Mobile Intended status: Informational 27 October 2026 Expires: 30 April 2027 Agent Authorization Center for User-Side Agent Authentication and Authorization draft-du-oauth-agent-authorization-center-00 Abstract This document proposes an Agent Authorization Center (AAC) for user- side intelligent agents, enabling them to access resource parties on behalf of users through either autonomous approval or human authorization modes. The AAC maintains user-agent associations and personalized authorization policies, balancing agent autonomy with user control. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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 30 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Du Expires 30 April 2027 [Page 1] Internet-Draft Agent Authorization Center October 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Agent Authorization Center Architecture . . . . . . . . . . . 3 2.1. Authorization Flow . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction With the rapid advancement of large language models (LLMs) and agent technologies, intelligent agents are evolving from simple conversational tools into digital assistants capable of autonomously executing complex tasks. Agents can represent users in completing travel planning, ticket booking, information retrieval, online shopping, and other operations, increasingly functioning as digital proxies for human users. However, the widespread deployment of agents faces a critical challenge: when an agent needs to access third-party resource parties (such as websites, APIs, or cloud services) on behalf of a user, how can identity authentication and authorization be securely and efficiently accomplished? The traditional OAuth 2.0 [RFC6749] framework assumes that authorization requests are initiated by users, who interact with the authorization server through a browser to complete authorization. However, the agent scenario introduces new characteristics: * Agents may operate over extended periods, making it impractical to interrupt users for interactive authorization each time. Du Expires 30 April 2027 [Page 2] Internet-Draft Agent Authorization Center October 2026 * Agents act on behalf of users, requiring a mechanism to express that "the user has pre-authorized this agent to act autonomously in this context". * Authorization policies are highly personalized across users, necessitating centralized policy management. This document proposes an Agent Authorization Center (AAC) architecture that serves as a trust anchor between agents and resource parties. The AAC maintains user agent authorization policies and supports two authorization modes: Autonomous Approval and Human Authorization, extending the OAuth 2.0 flow to accommodate agent scenarios. This mechanism is primarily designed for user-side agents, which deployed on personal user devices, bound to individual users, and acting on their behalf. This document distinguishes between two agent deployment forms: * User-side Agent: Deployed on personal user devices (smartphones, PCs, smart home devices), tightly bound to individual user identities, typically serving a single user. Examples include personal assistant agents that help users manage schedules, book tickets, and shop online. * Service-side Agent: Deployed on cloud servers, natively supporting high concurrency and serving large numbers of users. Examples include customer service agents on e-commerce platforms and enterprise workflow automation agents. This document focuses on the user-side agent scenario, where the agent acts as a direct proxy for an individual user and requires personalized authorization policy management. 2. Agent Authorization Center Architecture The AAC serves as the trust intermediary among users, agents, and resource parties, with the following responsibilities: * Maintaining user identity information; * Maintaining associations between users and agent groups, and between agent groups and individual agents; * Maintaining autonomous access policies for agents (or agent groups); * Making authorization decisions for agent access requests: autonomous approval or referral to human authorization. Du Expires 30 April 2027 [Page 3] Internet-Draft Agent Authorization Center October 2026 +-------------------+ | Authorization | | Center | | (AAC) | | - User Identity | | - Agent Policies | | - Auth Decision | +---------+---------+ ^ Auth Request/ | Decision | | +-------------------+ | +-------------------+ | User-side |------------+----------| Resource Party | | Agent | Token Swap | (Resource | | (Personal Device) | | Server) | +-------------------+ +-------------------+ | | Policy Query / User Feedback v +-------------------+ | User | | (Policy Configure)| +-------------------+ Figure 1: Agent Authorization Center Architecture 2.1. Authorization Flow The authorization flow for an Agent accessing a resource party on behalf of a user is as follows. Step 1: Agent sends an access request to the resource party, carrying the user identifier and the AAC identifier. Step 2: After receiving the access request, the resource party redirects the Agent to the AAC, triggering the authorization flow. In detail, the resource party sends an authorization guidance message to guide the Agent to initiate an access authorization request to the AAC corresponding to the AAC identifier. Step 3: On receiving the authorization guidance message, Agent sends an access authorization request to the AAC (carrying User ID, Agent ID, Resource Party information) in order to obtain an authorization code for accessing the resource party. Du Expires 30 April 2027 [Page 4] Internet-Draft Agent Authorization Center October 2026 Step 4: On receiving the access authorization request, AAC performs authorization mode decision: if the resource party is in the Agent's autonomous access list, select the Autonomous Approval mode; otherwise, select the Human Authorization mode (notify user for confirmation). Step 5: If the access authorization request is approved through either mode, AAC generates an authorization code and returns it to the Agent. Step 6: After receiving the authorization code, the Agent delivers the authorization code to the resource party (e.g., via the redirect URI). Step 7: The resource party exchanges the authorization code, redirect URI, and other information with the AAC's token endpoint to request an access token. Step 8: The AAC's authorization server returns an access token to the resource party, in which the user account identifier, the Agent identifier, and the AAC identifier should be included. Optionally, the token may include an authorization mode identifier indicating whether it was obtained through autonomous approval or human authorization. Step 9: The resource party validates the token and provides services according to the user's entitlements. In the Step 4, if the resource party is in the Agent's autonomous access list, it means a related policy is matched. The policy can be pre-configured by the user. Examples include: * If the resource party is in the autonomous access list, the AAC directly approves the access authorization request (Autonomous Approval); * If the resource party is in the forbidden list, the AAC rejects the access authorization request; * If the resource party is not in any list, the AAC notifies the user for confirmation (Human Authorization). When the Autonomous Approval policy is matched, the AAC would autonomously approve the access authorization request without human in the loop. When the Human Authorization policy is matched, the AAC would approve the access authorization request based on the authorization instruction received from the user. Du Expires 30 April 2027 [Page 5] Internet-Draft Agent Authorization Center October 2026 3. IANA Considerations TBD. 4. Security Considerations TBD. 5. Acknowledgements TBD. 6. References 6.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, . 6.2. Informative References [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . Author's Address Zongpeng Du China Mobile No.32 XuanWuMen West Street Beijing 100053 China Email: duzongpeng@foxmail.com Du Expires 30 April 2027 [Page 6]