OAuth2.0 Extension for Multi-AI Agent Collaboration: Applier-On-Behalf-Of Authorization

AI agents are capable of handling tasks. They can integrate multiple technologies such as natural language understanding, data analysis, and logical reasoning to meet multi-step and cross-scenario requirements. However, a single AI agent has a limited knowledge scope and restricted functions, making it difficult to independently complete complex tasks that span multiple professional domains and require different capabilities. Collaboration among a group of AI agents is an essential approach for such complex tasks. Taking the demand for "real-time health advice" as an example, this intent can be split into three tasks: "collect the user's health data", "predict the user's health status" and "provide health advice based on health status". These tasks need to be accomplished by corresponding professional sub-AI agents: the data collection agent is responsible for privacy-compliant data collection, the health status prediction agent invokes medical models for analysis, and the advice generation agent outputs solutions based on health guidelines. What's more, accordingto some existing research, a leading agent is necessary for coordination. In the above example, the leading agent can receive the intent "give me real-time health advice" from user, understand it and split it into tasks. Additionally, the leading agent can distribute these tasks to sub-AI agents. Finally, the leading agent can integrate the results of sub-AI agents to form a complete health advice. Without the leading agent, tasks are prone to confusion and results are difficult to integrate. In this collaborative scenario, if each sub-AI agent applies for permissions from the authorization server separately, the authorization server needs to verify the identity of each sub-AI agent one by one and generate access tokens for them. This will lead to problems such as frequent interactions, high computing resource consumption of the authorization server and low efficiency of the token issuance process. Therefore, this draft puts forward an authorization method: configure "task scheduling" and "result integration" rights for the leading agent, and let the leading agent interface with the authorization server centrally. This method can greatly simplify the authorization process of sub-AI agents and avoid efficiency loss caused by repeated interactions.

This protocol flow is modeled after and extends it with a *applier_id* field to enable authorization request by the applier.

| Resource | | | | Owner | | |<--(B) Authorization Grant----| | | | +----------------+ |Applier | | | (C) Authorization Grant +----------------+ | |--------(applier_id)--------->| | | | | Authorization | | | (D) Access Token | Server | | |<------(app=applier_id)-------| | +--------+ +----------------+ | | (E) Access Token* | v +--------+ +----------------+ | |-------(F) Access Token*----->| Resource | | Client | | Server | | |<---(G) Protected Resource----| | +--------+ +----------------+]]>

Before initiating the protocol, the applier registers with the authorization server, as defined in . In this draft, the applier's role or capability is incorporated into its registration process. For example, the applier's profile includes a "capability" parameter with the value "resolve intent and distribute tasks".

This section refers to step (A) and (B). The applier receives a requirement from the user, resolves it and determines the task(s) and client(s) needed to fulfill the requirement. For example, when the user sends the intent "give me real-time health advice" to the leading AI agent, the leading AI agent resolves this intent and identifies three tasks: task 1 (collect the user's health data), task 2 (predict the user's health status) and task 3 (provide health advice based on health status). The leading agent then utilizes the agent discovery process to select sub-AI agent(s) capable of performing the respective tasks. For instance, task 1 assigned to sub-AI agent 1, task 2 to sub-AI agent 2, and task 3 to sub-AI agent 3. In the subsequent authorization process proposed in this draft, the leading AI agent is designated as the applier, and the selected sub-AI agent(s) are designated as the client(s). The applier requests authorization from the resource owner, as defined in .

This section refers to step (C) and D). The applier requests an access token by authenticating with the authorization server and presenting the authorization grant, as defined in . The message may also include the following parameter: OPTIONAL. The identifier of the applier which is requesting access token on be half of the client(s). The authorization server authenticates the applier and validates that the applier is capable of requesting access tokens on behalf of client(s). For example, it checks whether the applier's profile includes a "capability" parameter whose value includes "distribute tasks". If the validation is successful, the authorization server may verify grants as defined in . Then the authorization server generates access token and send access token response message to the applier. The access token is similar to OAuth2.0, except that it consists of an additional claim to specify the applier. OPTIONAL. The identifier of the applier which is requesting access token on be half of the client(s). The access token includes one *app* parameter and multiple *sbj*-*aud*-*scope* pairs. Below is an example: { "iss": "authorization server ID", "app": "leading agent ID", "sbj": "sub AI agent1 ID", "aud": "resource server 1 ID", "sbj": "sub AI agent 2 ID", "aud": "resource server 1 ID", "resource server 2 ID", "sbj": "sub AI agent 3 ID", "aud": "resource server 2 ID", "resource server 3 ID" ... } If the validation fails, the access token response message may include the reason for failure. has defined types of error response. In this case, the authorization server may use a new error message "unauthorized_applier" to indicate that the applier is not capable of requesting access tokens on be half of client(s).

This section refers to step (E). The applier sends the task ID and access token* to the client(s). Based on local policies and regulations, the applier may use privacy protection mechanisms to process the access token. Thus, the access token* may be the same as the access token, or generated from the access token using privacy protection mechanisms. For example, the applier uses a selective disclosure algorithm to generate access token 1, access token 2, and access token 3 from the access token received in step (D). Access token 1 may include the leading agent ID and sub-AI agent 1 ID; access token2 may include the leading agent ID and sub-AI agent 2 ID; access token3 may include the leading agent ID and sub-AI agent 3 ID. The applier may then send access token 1 to sub-AI agent 1, access token 2 to sub-AI agent 2, and access token 3 to sub-AI agent 3. The client(s) validate the proof of the received access token* and check whether the applier ID refers to a trustworthy applier. For example, each AI agent is preconfigured with a list of trusted AI agents, and any one of the trusted AI agents that acts as a leading agent will pass the validation. If the validation fails, the client(s) may send a response message to the applier with a failure indication of "unknown_applier".

This section refers to step (F) and (G). The client(s) execute the task according to message received in step (E). When resources are needed, the client(s) request the protected resource from the resource server and present the access token*, as defined in . The resource server validates the access token*, as defined in . If the access token* includes multiple *sbj*-*aud* pairs, the resource server may verify that its own ID and the client's ID are in the same pair. In previous example of the access token, "sub-AI agent 1 ID"and "resource server 1 ID" are in the same pair. If the validation succeeds, the resource server may provide the resource to the client(s).