Network Working Group K. Yao Internet-Draft China Mobile Intended status: Informational 30 June 2025 Expires: 1 January 2026 Further considerations on AI Agent Authentication and Authorization Based on OAuth 2.0 Extension draft-yao-agent-auth-considerations-00 Abstract Agent Communication Network(ACN) is becoming a promising and fundamental infrastructure for most vertical industries. To construct and build a scalable and trustable ACN, authentication and authorization of AI agents are some of the most important issues that need to be solved. This document extends the model of OAuth 2.0 and proposes new workflows for AI agent authentication and authorization. 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 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Yao Expires 1 January 2026 [Page 1] Internet-Draft Agent AuthN and AuthZ June 2025 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. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. Aauth: Agent OBO Its User(s) . . . . . . . . . . . . . . . . 4 3.1. Example Case . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Aauth: Agent OBO Itself . . . . . . . . . . . . . . . . . . . 7 4.1. Example Case . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Aauth: Agent OBO Other Agent(s) . . . . . . . . . . . . . . . 9 5.1. Example Case . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Considerations on Other Important Factors . . . . . . . . . . 11 6.1. Grant Dynamicity . . . . . . . . . . . . . . . . . . . . 11 6.2. Specific Identity for AI Agent . . . . . . . . . . . . . 12 6.3. Can AI Agents Represent Users to Consent Requests? . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction With the rapid development of large language models(LLMs) and AI applications, AI agent is becoming an emerging entity that can help improve working efficiency. There are different types of AI agents, e.g. physical and virtual entities, and many promising use cases of AI agents have been mentioned in [I-D.rosenberg-ai-protocols]. All of these AI agents will join together to build a new Internet infrastructure, which is called as Agent Communication Network(ACN). To build such future nework is not easy, requirements on new protocols are also mentioned in [I-D.rosenberg-ai-protocols]. For Yao Expires 1 January 2026 [Page 2] Internet-Draft Agent AuthN and AuthZ June 2025 example, discovery mechasims of AI agents, routing and connection, etc. But the most intuitive and important part for protocols evolution is the authentication and authorization. The complexity of AI agent authentication and authorization exists in that agent may have different roles and capabilities. AI agents may work On-behalf-of(OBO) users, itself, or other AI agents. In different cases, there are different requirements on the authentication and authorization, leading to different workflows. More importantly, agents may communicate with API proxy server, like MCP server to call API and access external resources, this make the authentication and authorization problem more complex. [I-D.oauth-ai-agents-on-behalf-of-user] considers the case when AI agents work OBO their users, and [I-D.patwhite-aauth] defines the extension of OAuth 2.1 for AI agents. This document further considers more cases on AI agents authentication and authorization based on OAuth extensions. 2. Definition of Terms * AI Agent: an entity with built-in intelligence, which can help or replace humans implement jobs and improve work efficiency. * Types of AI Agents: - Physical AI Agent: an physical entity with embedded intelligence, usually refers to some AI terminals, e.g., AI robot, embodied AI. - Virtual AI Agent: an virtual entity that can provide intelligence, usually refers to some softwarized AI assistant, e.g., a chat assistant with a mobile application. * Ownership and Roles of AI Agents: - OBO User: the agent may require the authorization from user(s) to implement jobs for user(s). - OBO Agent Itself: the agent itself has identification and implements jobs and represents itself. - OBO Other Agent(s): the agent may represent other agents to implement some jobs, given that other agents may not have the capabilities to implement the jobs. * Agent Communication Network(ACN): a network infrastructure which supports the interconnection, routing, capabilities announcement, and task collaboration of different types of AI agents. Yao Expires 1 January 2026 [Page 3] Internet-Draft Agent AuthN and AuthZ June 2025 * Agent Identifier(AID): An independent identifier of AI agent. * API Proxy Server: A middlebox server that helps AI agent to call APIs or access external data resources. A typical example is the Model Context Protocol(MCP) server. * Domain: - Task-wise Domain: a temporary domain that is created to target on a specific job, when the job is finished, the domain is destroyed. A typical example is a domain that is created by 5G/6G core netowrk. - Application Domain: a durable domain that is created by a specific application, e.g., a web or mobile application offerred by cloud service providers. The definition of resource server, resource owner, authorization server, and client reuse the definition in [RFC6749]. 3. Aauth: Agent OBO Its User(s) 3.1. Example Case A typical use case of AI agent on-behalf-of the user to access public resources can be an virtual agent assitant. For example, a trip planning app assistant helps the user to plan trips. This case is obvious and similar ones have been mentioned in [I-D.rosenberg-ai-protocols]. In this case, when the trip assitant needs to search for the current balance of the user, it needs the authorization of the user to access his bank account app. While it may also need to search for hotels, and it may require the account of the user under some booking applications. In addition, it may also need to use some of the data stored in the cloud personal gallery, which may require temporary access token. Therefore, AI agent OBO user(s) need different levels of authentication and authorization to access these resources. 3.2. Model Figure 1 shows the extension of the OAuth 2.0 model proposed in [RFC6749]. There are several updates and new components in this model. The big difference is the introduction of AI agent and API proxy server. If under traditional OAuth 2.0 model, client(AI agent) will directly communicate with resource owners and resource servers. But this is not efficient and scalable in the AI era, since an agent may consulting many resource owners at the same time, and different resource owners may require different levels of privileges to access Yao Expires 1 January 2026 [Page 4] Internet-Draft Agent AuthN and AuthZ June 2025 the protected resources. To overcome the issue, industries have proposed Model Context Protocol(MCP). It introduces MCP server and protocol to let AI agents only communicate with the MCP server to request for resources. The MCP server will help AI agents to do API calling and specific data resource access. In Figure 1, MCP server refers to the API proxy server. In the diagram, API proxy server will communicate with different resource owners and resource servers. The agent may also support communicate directly with the resource owner and resource server. For example, the resource owner is another agent that is interconnected with the agent itself. Yao Expires 1 January 2026 [Page 5] Internet-Draft Agent AuthN and AuthZ June 2025 2 +--------+ +------------->Resource| |+------------+Owner 1 | || 3 +--------+ || 8 +--------+ || +-------->|Resource| +------+ || |+--------+Server 1| | +--+| || 9 +--------+ | <---+ || +-------> API +------+| | | Proxy| | | +-----|Server<-------+ | | | | | | | +-----+ | | | <-+ | 2 +--------+ | | +---^+-+ | +--------->|Resource| 1,7 | | || +--------------+Owner 2 | | |4,10 || 3 +--------+ | | || 8 +--------+ | | |+----------------->|Resource| +----+ 0 +-----+ | | +-------------------+Server 2| |User+--------> +---+ | 9 +--------+ | <--------+ <-----+ +----+ 11 | | 1 +--------+ | AI +----------------------->|Resource| |Agent<------------------------+Owner 3 | | | 4 +--------+ | +-----------+ 7 +--------+ | | +----------->|Resource| | <------------------------+Server 3| +--^-++ 9 +--------+ | | | | | | 5 +-------+ | +------------> Auth | +--------------+Servers| 6 +-------+ Figure 1: AI Agent OBO User Workflow 3.3. Workflow The detailed workflow of Figure 1 is as follows: * Step 0, the user initially asks for AI agent for some tasks via prompts. Yao Expires 1 January 2026 [Page 6] Internet-Draft Agent AuthN and AuthZ June 2025 * Step 1, the AI agent interprate the prompts and communicate with the API proxy server to search for particular data resources and implement function calling. Alternatively, the agent will ask the resource server for the grant if they are directly connected. * Step 2, the API proxy server ask for multiple resource owners for the grant of the access of the protected data resources. * Step 3, resource owners reply to the API server what authentication grant(e.g., authorization code) they need for the access of the required resource. * Step 4, the API proxy server will gather messsages from different resource owners and reply to the AI agent containing multiple authorization grants from different resource owners. Alternatively, the resource owner 3 will replies to the agent with the authorization grant directly. * Step 5, the AI agent communicates with different authorization servers with multiple authorization grants. * Step 6, auth servers reply to the AI agent with the required access tokens. * Step 7, AI agent replies to the API server with the required access tokens. Alternatively, it directly sends the access token to the resource server(resource server 3). * Step 8, the API proxy server send different access tokens to different resource servers respectively. * Step 9, resource servers send the protected data resources to the API proxy server. The resource server 3 directly sends the protected data resources to the AI agent. * Step 10, the API proxy server replies to the AI agent with the information that it needs. * Step 11, AI agent replies to the user with the answer. 4. Aauth: Agent OBO Itself Yao Expires 1 January 2026 [Page 7] Internet-Draft Agent AuthN and AuthZ June 2025 4.1. Example Case In addition to virtual AI agent, there is another type, physical AI agent. AI robots, embodied AI, and other AI terminals have differentiated capabilities to implement multiple jobs. For example, in a remote rescue case, an AI search and rescue vehicle, and an robot dog can be dynamically formed into a networked system. The robot dog can scan and transmit the live videos to remote console and control signals to the AI search and rescue vehicle, while the AI search and rescue vehicle can use its robotic arm to move obstacles based on the signals from the robot dog or the remote console. Some other similar cases are mentioned in [TR22.870]. Compared to the aforementioned case in which the agent is OBO its user, the major difference in this case is that agent need identification of itself, that is the agent identification(AID). In previous case, agent can be assigned a Client ID(CID). The scope of its authority is determined by its user, and is less than its users' authority scope. While if agent is OBO itself, it is the user. So it has the same privilege as the user. How to define the AID needs further discussion and is out of the scope of this document. 4.2. Model The model of the agent OBO itself can be extended from[I-D.ietf-oauth-v2-1]. As shown in Figure 2, the AI agent is the resource owner. When assigned with some specific tasks, it may enable some software functions, and then it will trigger the client within these software functions for authentication and authorization. +---------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| (AI Agent or | | | | Other owners) | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +---------+ +---------------+ Yao Expires 1 January 2026 [Page 8] Internet-Draft Agent AuthN and AuthZ June 2025 Figure 2: AI Agent OBO Itself Workflow 4.3. Workflow Detailed workflow is similar to [I-D.ietf-oauth-v2-1], and will not be stated in detail. 5. Aauth: Agent OBO Other Agent(s) 5.1. Example Case This case is more complex, but may be required if AI agents have differentiated capabilities and need to collaborate to finish some jobs, whatever the agents are from intra-domain or inter-domain, which has been discussed in [I-D.rosenberg-ai-protocols]. In this case, if one AI agent wants to access some protected data resources of other agents, or of the users of other agents. It needs the authorization from them. This is different compared to the situation that this agent only need to seek for grant from the user it represents. 5.2. Model Figure 3 shows the model when multiple agents work collaboratively, and there will be a chained authentication and authorization workflow. Before AI Agent A requests AI agent B to help it implement a job, there should be prior knowledge that both agents need mutual trust. If they come from the same domain, whatever it is a task-wise domain created by a console(e.g., 5G/6G core) or a durable domain created by a web application, they need verification from the 5G/6G core or the web application administrator. If they come from different domains, they may need verification from an open platform that organize and issue the AIDs. There are some ongoing work defining AID[I-D.narajala-ans],[I-D.narvaneni-agent-uri]. With this pre-verification, agents can communicate with each other. But when one agent(AI agent B) needs access of the protected data resource of the user of AI agent A or AI agent C itself, it still need temporary authentication and authorization. In this chained authentication and authorization workflow, the core idea here is to let the agent OBO user or the agent OBO itself always to communicate with the authorization server to get the access token. Yao Expires 1 January 2026 [Page 9] Internet-Draft Agent AuthN and AuthZ June 2025 +------+ | Auth | |Server| +-^-+--+ +------+ 3 +--------+ | | | +-------->Resource| | | | <--------+Owner 1 | 7| |8 +-----> API | 4 +--------+ | | | | Proxy| ++-v--+ | +---|Server| 11 +--------+ | AI | | | | +-------->Resource| |Agent| | | | <--------+Server 1| | C | | | | | 12 +--------+ +-^-+-+ | | +------+ | | 2,10| | | | | |5,13 6,9| |1,14 | | +----+ | | +-----+ | | |User| | | | +---+ | | | | +---> <-----+ +-+^-+ +-----+ | 2 +--------+ || | AI +----------------------->|Resource| 0||15 |Agent<------------------------+Owner 2 | +-v+--+ | B | 5 +--------+ | AI | 6,14 | +-----------+ 10 +--------+ |Agent<-------+ | +----------->|Resource| | A +-------> <------------------------+Server 2| | | 1,9 +-----+ 13 +--------+ +--^-++ | | | | 7 +------+ | +--------------------------> Auth | +----------------------------+Server| 8 +------+ Figure 3: AI Agent OBO Other Agents Workflow 5.3. Workflow The detailed workflow of Figure 3 is as follows: Step 0, a user asks its AI agent(AI agent A) for some help. Step 1, AI agent A redirects the help to Agent B when A is not capable, and Agent C asks for B's help too. Step 2, agent B ask API proxy server to call APIs. Agent may also request resource owner's grant for its protected data resources. Yao Expires 1 January 2026 [Page 10] Internet-Draft Agent AuthN and AuthZ June 2025 Step 3, the API proxy server send requests to resource owner 1. Step 4, the resource owner 1 send access grant to the API proxy server. Step 5, the API proxy server and resource owner 2 send the access grant to AI agent B. Step 6, AI agent B redirects the the access grants to AI agent A or AI agent C, considering the resource belong to whom. Step 7, AI agent A and AI agent C send access grants to authorization servers. Step 8, authorization servers replies with authorization tokens. Step 9, Agent A and agent C pass the access tokens to agent B. Step 10, AI agent B passes the access tokens to API proxy server or resource owner 2, considering what resource agent B wants to access. Step 11, the API proxy server passes the access token to resource owner 1. Step 12, resource owner 1 gives the protected data resource to the API proxy server. Step 13, agent B gather the data resources from the API proxy server and resource owner 2. Step 14, agent B sends back the processing result to agent A or agent C. Step 15, agent A processes further and sends back the final result to the user. 6. Considerations on Other Important Factors 6.1. Grant Dynamicity [RFC7591] mentions the mechasim to realize dynamic client registration. Whether and when to grant AI agents with short-lived or long-lived authentication and authorization may need further discussion, considering about various use cases that AI agents participant. Yao Expires 1 January 2026 [Page 11] Internet-Draft Agent AuthN and AuthZ June 2025 6.2. Specific Identity for AI Agent As the second and the third case mentions in the previous section, AI agents may have independent identities in ACN. The definition of AIDs is not within the scope of this document, but directly impacts the authentication and authorization methods. 6.3. Can AI Agents Represent Users to Consent Requests? In the third case mentioned in this document when agent is OBO other agents. This document assumes that agent can represent its user to request for access tokens, while the choice on whether to consent requests(authorization grant) is still left to the user or the agent(agent C). But it may evole to the situation that AI agent can represent its user to give permission if there are some pre- validation on the content scope that AI agent can give external grants independently. 7. Security Considerations There may exist security issues when spoofying AI agents seek for authentication and authorization for specific resources. Spoofying AI agents are created very similar to the validated AI agents. But they may hijack the access token to access the protected data resources from users or other agents. The methods to indentify and prevent these spoofying AI agents need further discussions. 8. IANA Considerations TBD. 9. Acknowledgements 10. References 10.1. Normative References [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, . 10.2. Informative References Yao Expires 1 January 2026 [Page 12] Internet-Draft Agent AuthN and AuthZ June 2025 [I-D.ietf-oauth-v2-1] Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1 Authorization Framework", Work in Progress, Internet- Draft, draft-ietf-oauth-v2-1-13, 28 May 2025, . [I-D.narajala-ans] Huang, K., Narajala, V. S., Habler, I., and A. Sheriff, "Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability", Work in Progress, Internet-Draft, draft-narajala-ans-00, 16 May 2025, . [I-D.narvaneni-agent-uri] Narvaneni, Y., "The agent:// Protocol -- A URI-Based Framework for Interoperable Agents", Work in Progress, Internet-Draft, draft-narvaneni-agent-uri-01, 21 April 2025, . [I-D.oauth-ai-agents-on-behalf-of-user] Thilina, T. and A. Dissanayaka, "OAuth 2.0 Extension: On- Behalf-Of User Authorization for AI Agents", Work in Progress, Internet-Draft, draft-oauth-ai-agents-on-behalf- of-user-01, 8 May 2025, . [I-D.patwhite-aauth] White, P., "AAuth - Agentic Authorization OAuth 2.1 Extension", Work in Progress, Internet-Draft, draft- patwhite-aauth-00, 13 May 2025, . [I-D.rosenberg-ai-protocols] Rosenberg, J. and C. F. Jennings, "Framework, Use Cases and Requirements for AI Agent Protocols", Work in Progress, Internet-Draft, draft-rosenberg-ai-protocols-00, 5 May 2025, . [TR22.870] 3GPP, "Study on 6G Use Cases and Service Requirements", n.d.. Yao Expires 1 January 2026 [Page 13] Internet-Draft Agent AuthN and AuthZ June 2025 Author's Address Kehan Yao China Mobile Email: yaokehan@chinamobile.com Yao Expires 1 January 2026 [Page 14]