authenticate / auth-required can't model per-session, request-correlated OAuth (e.g. MCP server OAuth)

Summary

AHP's authentication flow (auth/required + the authenticate command) models agent-level, statically-declared protected resources via RFC 6750 bearer-token push. It can't model a per-session, request-correlated OAuth flow — the shape MCP servers use — so a host bridging such a flow to AHP clients has no surface to express it.

Current model

• auth/required (server → client) carries a channel and a resource (an OAuth-protected resource identifier per RFC 9728).
• authenticate (client → server) pushes a Bearer token for that resource. AuthenticateParams.channel is narrowed to 'ahp-root://', and resource MUST match a ProtectedResourceMetadata.resource declared in AgentInfo.protectedResources:

export interface AuthenticateParams extends BaseParams {
  channel: 'ahp-root://';
  resource: string; // must match AgentInfo.protectedResources
  token: string;    // bearer token the client already obtained
}

So the model is "push me a bearer token for this declared, agent-level resource."

The gap

This can't represent an OAuth flow that is per-session and correlated to a specific pending request. As a concrete, publicly-available example, the github/copilot-sdk runtime emits an mcp.oauth_required event:

• it carries an oauthRequestId ("used to respond via session.respondToMcpOAuth()"), the MCP server name/URL, and an optional static client config (grant type, etc.);
• the client is expected to respond correlated by that request id, potentially completing an interactive authorization-code grant rather than just handing back a pre-obtained bearer token.

A host bridging such a backend to AHP clients has nowhere to:

1. advertise the pending request on the session channel — auth/required is geared to root-channel, agent-declared resources, and authenticate.channel is 'ahp-root://'-only; and
2. receive a request-correlated completion — authenticate carries only { resource, token }, with no field to echo back a specific request/correlation id, and assumes the client already holds a bearer token rather than completing a pending authorization tied to a particular request.

Suggested direction

Consider extending the authentication surface to cover per-session, request-correlated OAuth — for example:

• a session-channel auth/required variant carrying an opaque request/correlation id (and optional client-config hints), and
• an authenticate (or sibling) command variant that echoes that id and can carry an authorization result, not only a pre-obtained bearer token.

Happy to help shape this if it's useful — it's the one authentication shape that doesn't map onto the current commands.

Start by reading the current auth/required and authenticate definitions, including their channel, resource, and token fields. Compare them with the per-session, request-correlated OAuth flow described from the Copilot SDK and determine the protocol shape needed; done means the project agrees on an implementable extension and its correlation and authorization-result semantics.