From dfebcbbd332e47da11dd0c07ce8b568bc7a41fb2 Mon Sep 17 00:00:00 2001 From: "Anna.Zhdan" Date: Thu, 11 Dec 2025 06:42:41 +0100 Subject: [PATCH 01/10] Add Authentication RFD --- docs/rfds/auth.mdx | 131 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 docs/rfds/auth.mdx diff --git a/docs/rfds/auth.mdx b/docs/rfds/auth.mdx new file mode 100644 index 00000000..01c78fb4 --- /dev/null +++ b/docs/rfds/auth.mdx @@ -0,0 +1,131 @@ +--- +title: "AUTHENTICATION" +--- + +Author(s): [anna239](https://github.com/anna239) + +## Elevator pitch + +> What are you proposing to change? + +I suggest adding more information about auth methods that agent supports, which will allow clients to draw more appropriate UI. + +## Status quo + +> How do things work today and what problems does this cause? Why would we change things? + +Agents have different ways of authenticating users: env vars with api keys, running a command like ` login`, some just open a browser and use oauth. +[AuthMethod](https://agentclientprotocol.com/protocol/schema#authmethod) does not really tell the client what should be done to authenticate. This means we can't show user a control for entering key if an aggent support auth through env var. + +## What we propose to do about it + +> What are you proposing to improve the situation? + +We can add different types of AuthMethods, so that clients can show some UI for them. For example, this auth method +```json +{ + "id": "123", + "name": "OpenAI api key", + "description": "Provide your key", + "type": "envVar", + "varName": "OPEN_AI_KEY" +} +``` +would allow client to prompt user to enter a key, then client can provide this key to an agent via `OPEN_AI_KEY` env variable. + +## Shiny future + +> How will things will play out once this feature exists? + +It will be easier for end-users to start using an agent from inside the IDE as auth process will be more straightforward + +## Implementation details and plan + +> Tell me more about your implementation. What is your detailed implementation plan? + +I suggest adding following auth types: + +1. Env variable + +A user can enter a key and a client will pass it to the agent as an env variable + +```json +{ + "id": "123", + "name": "OpenAI api key", + "description": "Provide your key", + "type": "envVar", + "varName": "OPEN_AI_KEY" , + "link": "OPTIONAL link to a page where user can get their key" +} +``` + +2. Start argument + +A user can enter a key and a client will pass it to the agent as a start parameter + +```json +{ + "id": "123", + "name": "OpenAI api key", + "description": "Provide your key", + "type": "startParam", + "paramName": "OPEN_AI_KEY" , + "link": "OPTIONAL link to a page where user can get their key" +} +``` + +3. Agent auth + +Same as what there is now -- agent handles the auth itself, this should be default type if no type is provided for backward compatibility + +```json +{ + "id": "123", + "name": "Agent", + "description": "Authenticate through agent", + "type": "agent" +} +``` + +4. Provided key + +User can enter the key and client should pass it to the agent via [AuthenticateRequest](https://agentclientprotocol.com/protocol/schema#authenticaterequest) + +```json +{ + "id": "123", + "name": "OpenAI api key", + "description": "Provide your key", + "type": "enterKey", + "link": "OPTIONAL link to a page where user can get their key" +} +``` + +for this case [AuthenticateRequest](https://agentclientprotocol.com/protocol/schema#authenticaterequest) should also be updated. I suggest adding optional authParams property + +```json +{ + "methodId": "123", + "authParams": { + "key": "...." + } +} +``` + +### AuthErrors + +It might be useful to include a list of AuthMethod ids to the AUTH_REQUIRED JsonRpc error. Why do we need this if they're already shared during `initialize`: +All supported auth methods are shared during `initialize`. When user starts a session, they've already selected a model, which can narrow down a list of options. + +## Frequently asked questions + +> What questions have arisen over the course of authoring this document or during subsequent discussions? + +### What alternative approaches did you consider, and why did you settle on this one? + +Alternative approach would be to include this information to an agent's declaration making it more static, see [Registry RFD](https://github.com/agentclientprotocol/agent-client-protocol/pull/289) + +## Revision history + + From dfafc9d1e829f19a5cb0ed867a0aba50da5b8db4 Mon Sep 17 00:00:00 2001 From: "Anna.Zhdan" Date: Thu, 11 Dec 2025 06:46:09 +0100 Subject: [PATCH 02/10] fix formating --- docs/rfds/auth.mdx | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/rfds/auth.mdx b/docs/rfds/auth.mdx index 01c78fb4..000cbdc6 100644 --- a/docs/rfds/auth.mdx +++ b/docs/rfds/auth.mdx @@ -22,6 +22,7 @@ Agents have different ways of authenticating users: env vars with api keys, runn > What are you proposing to improve the situation? We can add different types of AuthMethods, so that clients can show some UI for them. For example, this auth method + ```json { "id": "123", @@ -31,6 +32,7 @@ We can add different types of AuthMethods, so that clients can show some UI for "varName": "OPEN_AI_KEY" } ``` + would allow client to prompt user to enter a key, then client can provide this key to an agent via `OPEN_AI_KEY` env variable. ## Shiny future @@ -55,7 +57,7 @@ A user can enter a key and a client will pass it to the agent as an env variable "name": "OpenAI api key", "description": "Provide your key", "type": "envVar", - "varName": "OPEN_AI_KEY" , + "varName": "OPEN_AI_KEY", "link": "OPTIONAL link to a page where user can get their key" } ``` @@ -70,7 +72,7 @@ A user can enter a key and a client will pass it to the agent as a start paramet "name": "OpenAI api key", "description": "Provide your key", "type": "startParam", - "paramName": "OPEN_AI_KEY" , + "paramName": "OPEN_AI_KEY", "link": "OPTIONAL link to a page where user can get their key" } ``` From f46f8a8c595435378feb72ecbed45cf94ff3d9f7 Mon Sep 17 00:00:00 2001 From: "Anna.Zhdan" Date: Sat, 13 Dec 2025 20:22:52 +0100 Subject: [PATCH 03/10] Add suggestion for MCP-like elicitation approach for oauth authnetication --- docs/rfds/auth.mdx | 47 ++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 41 insertions(+), 6 deletions(-) diff --git a/docs/rfds/auth.mdx b/docs/rfds/auth.mdx index 000cbdc6..a0b07b9b 100644 --- a/docs/rfds/auth.mdx +++ b/docs/rfds/auth.mdx @@ -15,7 +15,7 @@ I suggest adding more information about auth methods that agent supports, which > How do things work today and what problems does this cause? Why would we change things? Agents have different ways of authenticating users: env vars with api keys, running a command like ` login`, some just open a browser and use oauth. -[AuthMethod](https://agentclientprotocol.com/protocol/schema#authmethod) does not really tell the client what should be done to authenticate. This means we can't show user a control for entering key if an aggent support auth through env var. +[AuthMethod](https://agentclientprotocol.com/protocol/schema#authmethod) does not really tell the client what should be done to authenticate. This means we can't show the user a control for entering key if an aggent support auth through env var. ## What we propose to do about it @@ -64,7 +64,7 @@ A user can enter a key and a client will pass it to the agent as an env variable 2. Start argument -A user can enter a key and a client will pass it to the agent as a start parameter +A user can enter a key, and a client will pass it to the agent as a start parameter ```json { @@ -79,7 +79,7 @@ A user can enter a key and a client will pass it to the agent as a start paramet 3. Agent auth -Same as what there is now -- agent handles the auth itself, this should be default type if no type is provided for backward compatibility +Same as what there is now – agent handles the auth itself, this should be a default type if no type is provided for backward compatibility ```json { @@ -90,9 +90,40 @@ Same as what there is now -- agent handles the auth itself, this should be defau } ``` +To better handle oauth scenarios, we can add a mechanism like (MCP-elicitation)[https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation] +User sends authenticate request with method id; then server calls an `elicitation/create` method on a client, that includes a link to an oauth provider and `authenticateRequestId` so that we can clearly link the request with the auth request. + +```json +{ + "jsonrpc": "2.0", + "id": 3, + "method": "elicitation/create", + "params": { + "authenticateRequestId": "123", + "url": "https://mcp.example.com/ui/set_api_key", + "message": "Please provide your API key to continue." + } +} +``` + +Client then allows user to open a browser and authenticate themselves. Agent then responds to an elicitation request with a key: + +```json +{ + "jsonrpc": "2.0", + "id": 3, + "result": { + "action": "accept" + } +} +``` + +and then responds to the original `authenticate` request. + + 4. Provided key -User can enter the key and client should pass it to the agent via [AuthenticateRequest](https://agentclientprotocol.com/protocol/schema#authenticaterequest) +User can enter the key and a client should pass it to the agent via [AuthenticateRequest](https://agentclientprotocol.com/protocol/schema#authenticaterequest) ```json { @@ -104,7 +135,7 @@ User can enter the key and client should pass it to the agent via [AuthenticateR } ``` -for this case [AuthenticateRequest](https://agentclientprotocol.com/protocol/schema#authenticaterequest) should also be updated. I suggest adding optional authParams property +in this case [AuthenticateRequest](https://agentclientprotocol.com/protocol/schema#authenticaterequest) should also be updated. I suggest adding an optional authParams property ```json { @@ -115,6 +146,8 @@ for this case [AuthenticateRequest](https://agentclientprotocol.com/protocol/sch } ``` +This approach also requires adding a new `elicitation` client capability. If the client does not support this capability, agent MUST NOT return such an authMethod in the `initialize` response. + ### AuthErrors It might be useful to include a list of AuthMethod ids to the AUTH_REQUIRED JsonRpc error. Why do we need this if they're already shared during `initialize`: @@ -126,7 +159,9 @@ All supported auth methods are shared during `initialize`. When user starts a se ### What alternative approaches did you consider, and why did you settle on this one? -Alternative approach would be to include this information to an agent's declaration making it more static, see [Registry RFD](https://github.com/agentclientprotocol/agent-client-protocol/pull/289) +An alternative approach would be to include this information to an agent's declaration making it more static, see [Registry RFD](https://github.com/agentclientprotocol/agent-client-protocol/pull/289) + +There is also an alternative to adding a separate `elicitation` capability, which is to create a separate auth type for this. Then the client can decide themselves if they support it or not. ## Revision history From af924bfc7a5e8f585ef37f6711027b63df5aa834 Mon Sep 17 00:00:00 2001 From: "Anna.Zhdan" Date: Sat, 13 Dec 2025 20:26:05 +0100 Subject: [PATCH 04/10] Add suggestion for MCP-like elicitation approach for oauth authnetication --- docs/rfds/auth.mdx | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/rfds/auth.mdx b/docs/rfds/auth.mdx index a0b07b9b..24306a36 100644 --- a/docs/rfds/auth.mdx +++ b/docs/rfds/auth.mdx @@ -120,7 +120,6 @@ Client then allows user to open a browser and authenticate themselves. Agent the and then responds to the original `authenticate` request. - 4. Provided key User can enter the key and a client should pass it to the agent via [AuthenticateRequest](https://agentclientprotocol.com/protocol/schema#authenticaterequest) From a24533a500fff3256fa8ea763ca3159c00efbfb0 Mon Sep 17 00:00:00 2001 From: "Anna.Zhdan" Date: Tue, 23 Dec 2025 15:58:06 +0100 Subject: [PATCH 05/10] Update auth rfd --- docs/rfds/auth.mdx | 77 ++++++++++++++++------------------------------ 1 file changed, 26 insertions(+), 51 deletions(-) diff --git a/docs/rfds/auth.mdx b/docs/rfds/auth.mdx index 24306a36..92c1250e 100644 --- a/docs/rfds/auth.mdx +++ b/docs/rfds/auth.mdx @@ -58,7 +58,8 @@ A user can enter a key and a client will pass it to the agent as an env variable "description": "Provide your key", "type": "envVar", "varName": "OPEN_AI_KEY", - "link": "OPTIONAL link to a page where user can get their key" + "link": "OPTIONAL link to a page where user can get their key", + "requiresRestart": true // default } ``` @@ -73,7 +74,8 @@ A user can enter a key, and a client will pass it to the agent as a start parame "description": "Provide your key", "type": "startParam", "paramName": "OPEN_AI_KEY", - "link": "OPTIONAL link to a page where user can get their key" + "link": "OPTIONAL link to a page where user can get their key", + "requiresRestart": true // default } ``` @@ -86,72 +88,43 @@ Same as what there is now – agent handles the auth itself, this should be a de "id": "123", "name": "Agent", "description": "Authenticate through agent", - "type": "agent" + "type": "agent", + "requiresRestart": false // default, can be changed } ``` -To better handle oauth scenarios, we can add a mechanism like (MCP-elicitation)[https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation] -User sends authenticate request with method id; then server calls an `elicitation/create` method on a client, that includes a link to an oauth provider and `authenticateRequestId` so that we can clearly link the request with the auth request. +4. Terminal auth -```json -{ - "jsonrpc": "2.0", - "id": 3, - "method": "elicitation/create", - "params": { - "authenticateRequestId": "123", - "url": "https://mcp.example.com/ui/set_api_key", - "message": "Please provide your API key to continue." - } -} -``` - -Client then allows user to open a browser and authenticate themselves. Agent then responds to an elicitation request with a key: - -```json -{ - "jsonrpc": "2.0", - "id": 3, - "result": { - "action": "accept" - } -} -``` - -and then responds to the original `authenticate` request. - -4. Provided key - -User can enter the key and a client should pass it to the agent via [AuthenticateRequest](https://agentclientprotocol.com/protocol/schema#authenticaterequest) +What's now done with `terminal-auth` capability and _meta field, for backward compatibility clients might want to read properties from both _meta and the object itself. +This means that the client should run the provided command themselves in the terminal and let user interact with that terminal ```json { "id": "123", - "name": "OpenAI api key", - "description": "Provide your key", - "type": "enterKey", - "link": "OPTIONAL link to a page where user can get their key" + "name": "Run in terminal", + "type": "terminal", + "command": "/path/to/command", + "args": ["--setup"], + "env": {"VAR1": "value1", "VAR2": "value2"}, + "label": "Setup Label", + "requiresRestart": true // default, can be changed } -``` -in this case [AuthenticateRequest](https://agentclientprotocol.com/protocol/schema#authenticaterequest) should also be updated. I suggest adding an optional authParams property - -```json -{ - "methodId": "123", - "authParams": { - "key": "...." - } -} ``` -This approach also requires adding a new `elicitation` client capability. If the client does not support this capability, agent MUST NOT return such an authMethod in the `initialize` response. - ### AuthErrors It might be useful to include a list of AuthMethod ids to the AUTH_REQUIRED JsonRpc error. Why do we need this if they're already shared during `initialize`: All supported auth methods are shared during `initialize`. When user starts a session, they've already selected a model, which can narrow down a list of options. +```json +{ + "jsonrpc":"2.0", + "id":2, + "error":{"code":-32000,"message":"Authentication required", "authMethods":[{"id":"chatgpt","name":"Login with ChatGPT","description":"Use your ChatGPT login with Codex CLI (requires a paid ChatGPT subscription)"}]} +} +``` + ## Frequently asked questions > What questions have arisen over the course of authoring this document or during subsequent discussions? @@ -165,3 +138,5 @@ There is also an alternative to adding a separate `elicitation` capability, whic ## Revision history + +There was a part about elicitations https://github.com/agentclientprotocol/agent-client-protocol/blob/939ef116a1b14016e4e3808b8764237250afa253/docs/rfds/auth.mdx removed it for now, will move to a separate rfd \ No newline at end of file From a90022883782b4bdb1f290ed168393121ec0a5ae Mon Sep 17 00:00:00 2001 From: "Anna.Zhdan" Date: Tue, 23 Dec 2025 16:08:55 +0100 Subject: [PATCH 06/10] fix formatting --- docs/rfds/auth.mdx | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/docs/rfds/auth.mdx b/docs/rfds/auth.mdx index 92c1250e..f3db45b7 100644 --- a/docs/rfds/auth.mdx +++ b/docs/rfds/auth.mdx @@ -95,7 +95,7 @@ Same as what there is now – agent handles the auth itself, this should be a de 4. Terminal auth -What's now done with `terminal-auth` capability and _meta field, for backward compatibility clients might want to read properties from both _meta and the object itself. +What's now done with `terminal-auth` capability and \_meta field, for backward compatibility clients might want to read properties from both \_meta and the object itself. This means that the client should run the provided command themselves in the terminal and let user interact with that terminal ```json @@ -105,11 +105,10 @@ This means that the client should run the provided command themselves in the ter "type": "terminal", "command": "/path/to/command", "args": ["--setup"], - "env": {"VAR1": "value1", "VAR2": "value2"}, + "env": { "VAR1": "value1", "VAR2": "value2" }, "label": "Setup Label", "requiresRestart": true // default, can be changed } - ``` ### AuthErrors @@ -119,9 +118,19 @@ All supported auth methods are shared during `initialize`. When user starts a se ```json { - "jsonrpc":"2.0", - "id":2, - "error":{"code":-32000,"message":"Authentication required", "authMethods":[{"id":"chatgpt","name":"Login with ChatGPT","description":"Use your ChatGPT login with Codex CLI (requires a paid ChatGPT subscription)"}]} + "jsonrpc": "2.0", + "id": 2, + "error": { + "code": -32000, + "message": "Authentication required", + "authMethods": [ + { + "id": "chatgpt", + "name": "Login with ChatGPT", + "description": "Use your ChatGPT login with Codex CLI (requires a paid ChatGPT subscription)" + } + ] + } } ``` @@ -139,4 +148,4 @@ There is also an alternative to adding a separate `elicitation` capability, whic -There was a part about elicitations https://github.com/agentclientprotocol/agent-client-protocol/blob/939ef116a1b14016e4e3808b8764237250afa253/docs/rfds/auth.mdx removed it for now, will move to a separate rfd \ No newline at end of file +There was a part about elicitations https://github.com/agentclientprotocol/agent-client-protocol/blob/939ef116a1b14016e4e3808b8764237250afa253/docs/rfds/auth.mdx removed it for now, will move to a separate rfd From e0da39cace74197a945fc53c41737cdc3759d909 Mon Sep 17 00:00:00 2001 From: "Anna.Zhdan" Date: Sun, 11 Jan 2026 07:18:35 +0100 Subject: [PATCH 07/10] fix snake case --- docs/rfds/auth.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/rfds/auth.mdx b/docs/rfds/auth.mdx index f3db45b7..f3479e7a 100644 --- a/docs/rfds/auth.mdx +++ b/docs/rfds/auth.mdx @@ -28,7 +28,7 @@ We can add different types of AuthMethods, so that clients can show some UI for "id": "123", "name": "OpenAI api key", "description": "Provide your key", - "type": "envVar", + "type": "env_var", "varName": "OPEN_AI_KEY" } ``` @@ -56,7 +56,7 @@ A user can enter a key and a client will pass it to the agent as an env variable "id": "123", "name": "OpenAI api key", "description": "Provide your key", - "type": "envVar", + "type": "env_var", "varName": "OPEN_AI_KEY", "link": "OPTIONAL link to a page where user can get their key", "requiresRestart": true // default From 71a61b5042d612a1176bbfb24aa69b05013ed6f3 Mon Sep 17 00:00:00 2001 From: Anna Zhdan Date: Sun, 11 Jan 2026 07:19:05 +0100 Subject: [PATCH 08/10] Update docs/rfds/auth.mdx Co-authored-by: Niko Matsakis --- docs/rfds/auth.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfds/auth.mdx b/docs/rfds/auth.mdx index f3479e7a..891ea886 100644 --- a/docs/rfds/auth.mdx +++ b/docs/rfds/auth.mdx @@ -15,7 +15,7 @@ I suggest adding more information about auth methods that agent supports, which > How do things work today and what problems does this cause? Why would we change things? Agents have different ways of authenticating users: env vars with api keys, running a command like ` login`, some just open a browser and use oauth. -[AuthMethod](https://agentclientprotocol.com/protocol/schema#authmethod) does not really tell the client what should be done to authenticate. This means we can't show the user a control for entering key if an aggent support auth through env var. +[AuthMethod](https://agentclientprotocol.com/protocol/schema#authmethod) does not really tell the client what should be done to authenticate. This means we can't show the user a control for entering key if an agent supports auth through env var. ## What we propose to do about it From 4d2376e882fa31638af8fac240c5612371e5d738 Mon Sep 17 00:00:00 2001 From: Ben Brandt Date: Wed, 14 Jan 2026 14:49:24 +0100 Subject: [PATCH 09/10] Update based on CM discussion --- docs/rfds/auth.mdx | 73 +++++++++++++++++----------------------------- 1 file changed, 26 insertions(+), 47 deletions(-) diff --git a/docs/rfds/auth.mdx b/docs/rfds/auth.mdx index 891ea886..e6a0dac6 100644 --- a/docs/rfds/auth.mdx +++ b/docs/rfds/auth.mdx @@ -1,5 +1,5 @@ --- -title: "AUTHENTICATION" +title: "Authentication Methods" --- Author(s): [anna239](https://github.com/anna239) @@ -17,23 +17,13 @@ I suggest adding more information about auth methods that agent supports, which Agents have different ways of authenticating users: env vars with api keys, running a command like ` login`, some just open a browser and use oauth. [AuthMethod](https://agentclientprotocol.com/protocol/schema#authmethod) does not really tell the client what should be done to authenticate. This means we can't show the user a control for entering key if an agent supports auth through env var. +Very few agents can authenticate fully on their own without user input, so agents with ACP auth support are limited in the methods they can offer, or require manual setup before being run as an ACP agent. + ## What we propose to do about it > What are you proposing to improve the situation? -We can add different types of AuthMethods, so that clients can show some UI for them. For example, this auth method - -```json -{ - "id": "123", - "name": "OpenAI api key", - "description": "Provide your key", - "type": "env_var", - "varName": "OPEN_AI_KEY" -} -``` - -would allow client to prompt user to enter a key, then client can provide this key to an agent via `OPEN_AI_KEY` env variable. +We can add addition types of AuthMethods, to provide clients with additional information so they can assist in the login process. ## Shiny future @@ -47,70 +37,57 @@ It will be easier for end-users to start using an agent from inside the IDE as a I suggest adding following auth types: -1. Env variable +1. Agent auth -A user can enter a key and a client will pass it to the agent as an env variable +Same as what there is now – agent handles the auth itself, this should be a default type if no type is provided for backward compatibility ```json { "id": "123", - "name": "OpenAI api key", - "description": "Provide your key", - "type": "env_var", - "varName": "OPEN_AI_KEY", - "link": "OPTIONAL link to a page where user can get their key", - "requiresRestart": true // default + "name": "Agent", + "description": "Authenticate through agent", + "type": "agent" // Optional/default value } ``` -2. Start argument +2. Env variable -A user can enter a key, and a client will pass it to the agent as a start parameter +A user can enter a key and a client will pass it to the agent as an env variable ```json { "id": "123", "name": "OpenAI api key", "description": "Provide your key", - "type": "startParam", - "paramName": "OPEN_AI_KEY", - "link": "OPTIONAL link to a page where user can get their key", - "requiresRestart": true // default + "type": "env_var", + "varName": "OPEN_AI_KEY", + "link": "OPTIONAL link to a page where user can get their key" } ``` -3. Agent auth +Since this would need to be supplied to the agent when the process is started, the client can check if it already passed such an env variable to the process, in which case the user can click on the button and the agent will read the already available key. -Same as what there is now – agent handles the auth itself, this should be a default type if no type is provided for backward compatibility +Otherwise, when the user clicks the button, the client could restart the agent process with the desired env variable, and then automatically send the authenticate message with the correct id to sign in for the user. -```json -{ - "id": "123", - "name": "Agent", - "description": "Authenticate through agent", - "type": "agent", - "requiresRestart": false // default, can be changed -} -``` +3. Terminal Auth -4. Terminal auth - -What's now done with `terminal-auth` capability and \_meta field, for backward compatibility clients might want to read properties from both \_meta and the object itself. -This means that the client should run the provided command themselves in the terminal and let user interact with that terminal +There have been experiments for a "terminal-auth" experience as a fallback. This requires the client to be able to run an interactive terminal for the user to login via a TUI. ```json { "id": "123", "name": "Run in terminal", + "description": "Setup Label", "type": "terminal", - "command": "/path/to/command", "args": ["--setup"], - "env": { "VAR1": "value1", "VAR2": "value2" }, - "label": "Setup Label", - "requiresRestart": true // default, can be changed + "env": { "VAR1": "value1", "VAR2": "value2" } } ``` +The `command` cannot be specified, the client will invoke the exact same binary with the exact same setup. The agent can supply additional arguments and environment variables as necessary. These will be supplied in **addition** to any args/env supplied by default when the server is started. So agents will need to have a way to kickoff their interactive login flow even if normal acp commands/arguments are supplied as well. + +This is so that the agent doesn't need to know about the environment it is running in. It can't know the absolute path necessarily, and shouldn't be able to supply other commands or programs to minimize security issues. + ### AuthErrors It might be useful to include a list of AuthMethod ids to the AUTH_REQUIRED JsonRpc error. Why do we need this if they're already shared during `initialize`: @@ -149,3 +126,5 @@ There is also an alternative to adding a separate `elicitation` capability, whic There was a part about elicitations https://github.com/agentclientprotocol/agent-client-protocol/blob/939ef116a1b14016e4e3808b8764237250afa253/docs/rfds/auth.mdx removed it for now, will move to a separate rfd + +- 2026-01-14: Updates based on Core Maintainer discussion From 93d600cfce3d8c41ca48e383356ccf2b9caea498 Mon Sep 17 00:00:00 2001 From: Ben Brandt Date: Wed, 14 Jan 2026 15:24:22 +0100 Subject: [PATCH 10/10] Update website --- docs/docs.json | 3 ++- docs/rfds/{auth.mdx => auth-methods.mdx} | 0 docs/updates.mdx | 7 +++++++ 3 files changed, 9 insertions(+), 1 deletion(-) rename docs/rfds/{auth.mdx => auth-methods.mdx} (100%) diff --git a/docs/docs.json b/docs/docs.json index 560ab50e..195a2d61 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -115,7 +115,8 @@ "rfds/proxy-chains", "rfds/mcp-over-acp", "rfds/session-usage", - "rfds/acp-agent-registry" + "rfds/acp-agent-registry", + "rfds/auth-methods" ] }, { "group": "Preview", "pages": [] }, diff --git a/docs/rfds/auth.mdx b/docs/rfds/auth-methods.mdx similarity index 100% rename from docs/rfds/auth.mdx rename to docs/rfds/auth-methods.mdx diff --git a/docs/updates.mdx b/docs/updates.mdx index c2e28423..4ae79f34 100644 --- a/docs/updates.mdx +++ b/docs/updates.mdx @@ -4,6 +4,13 @@ description: Updates and announcements about the Agent Client Protocol rss: true --- + +## Authentication Methods RFD moves to Draft stage + +The RFD for creating additional types of authentication methods has been moved to Draft stage. Please review the [RFD](./rfds/auth-methods) for more information on the current proposal and provide feedback as work on the implementation begins. + + + ## Agent Registry RFD moves to Draft stage