



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,
              <https://www.rfc-editor.org/rfc/rfc6749>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc7591>.

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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              v2-1-13>.

   [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, <https://datatracker.ietf.org/doc/html/draft-
              narajala-ans-00>.

   [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, <https://datatracker.ietf.org/doc/html/draft-
              narvaneni-agent-uri-01>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-oauth-ai-
              agents-on-behalf-of-user-01>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-patwhite-
              aauth-00>.

   [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, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

   [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]
