]> TwoGenIdentity

embesozzi@twogenidentity.com

Security Independent Submission oauth agent native authorization elicitation ai agents This document defines a Structured Elicitation extension to the OAuth 2.0 First-Party Applications (FiPA) specification , establishing a standard metadata format for FiPA authorization challenge responses. FiPA leaves the format for advertising available authenticators and their required inputs undefined, preventing interoperable implementation by AI Agents and other non-browser clients. This extension adds an elicitations array to the FiPA Authorization Challenge Response, providing a standard metadata format for authenticator challenges. Model Context Protocol (MCP) Elicitation is the normative reference binding. This specification covers the just-in-time (JIT) authorization for AI Agents executing on behalf of users in Human-to-Agent (H2A) flows. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction

Applicability AI Agents operate autonomously and do not inherently distinguish routine operations from sensitive ones. When an agent encounters an operation requiring step-up authentication or explicit user approval, a just-in-time (JIT) authorization gate is needed: the agent must pause, surface a structured challenge to the human user, and obtain a cryptographic proof — an OAuth token — before proceeding. The FiPA specification provides the challenge/response wire protocol for this gate. This extension defines the metadata format that makes FiPA challenges machine-readable for agent runtimes. This extension applies when the client is an AI Agent acting on behalf of a human user (see Section 1.2), the authorization server supports the FiPA challenge/response protocol, and the agent runtime supports a Structured Elicitation mechanism (Section 4), with MCP Elicitation as the normative reference implementation.

Human-to-Agent (H2A) Communication Model This extension addresses the Human-to-Agent (H2A) communication pattern. In this pattern, a human user interacts with an AI Agent that acts as a first-party OAuth client on their behalf. The AI Agent orchestrates the FiPA challenge/response cycle but cannot independently satisfy authentication challenges that require human interaction — such as entering a TOTP code or completing a WebAuthn ceremony. The Structured Elicitation mechanism defined in Section 4 is the channel through which the authorization server communicates challenge requirements back to the human user via the agent runtime. The agent runtime presents the challenge to the human, collects the response, and forwards it to the authorization server as an Authorization Challenge Request. This contrasts with Agent-to-Agent (A2A) patterns, in which an autonomous agent satisfies authorization challenges without human involvement. The present document is scoped to H2A interactions; A2A authorization is outside the scope of this specification.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses terminology defined in , , and . The following terms are used as defined:

• Authorization Server (AS): As defined in .
• Just-In-Time (JIT) Authorization: An authorization pattern in which a fresh credential challenge is issued at the moment a sensitive action is attempted, rather than relying solely on the trust established at initial authentication. This extension enables JIT Authorization by providing the structured metadata needed for agent runtimes to surface mid-flow challenges to the human user.
• Structured Elicitation: The abstract mechanism by which an agent runtime requests structured user input mid-flow and returns a structured response. MCP Elicitation is a conformant implementation of this mechanism and serves as the normative reference implementation for this specification.
• Human-to-Agent (H2A) Communication: The interaction pattern in which a human user delegates actions to an AI Agent that acts as a first-party OAuth client. The agent orchestrates protocol flows on behalf of the user.
• First-Party AI Agent: An AI agent whose client runtime is built and controlled by the same operator as the server-side components and authorization server. The agent MAY implement FiPA-specific elicitation extensions.
• Third-Party AI Agent: An AI agent whose client runtime is a product provided by a third party. The implementer cannot modify client elicitation handling.

Protocol Overview This extension operates within the FiPA challenge/response cycle defined in . A FiPA authorization request that requires additional authentication receives an Authorization Challenge Response: The auth_session binds all subsequent requests to this authentication context. FiPA supports multi-step flows via continued challenge/response cycles on the same auth_session. This extension adds an elicitations array to the Authorization Challenge Response. Each entry in the array describes one authenticator challenge the human user must complete. The agent runtime translates each entry into a Structured Elicitation request directed at the human user, collects the response, and submits it in the next Authorization Challenge Request. Upon completion of the challenge/response cycle, the authorization server issues an authorization code or token bound to the auth_session. This token serves as cryptographic proof that a human user satisfied the required authentication challenge at a specific point in time, enabling the MCP server to enforce JIT authorization before executing sensitive operations.

Elicitation Extension

Response Format The elicitations array is added to the FiPA insufficient_authorization error response body. Each entry carries the parameters needed for the agent runtime to present a structured challenge to the human user. Fields per entry:

Field	Required	Description
mode	REQUIRED	Interaction mode. "form" for in-band structured data collection using a JSON Schema.
message	REQUIRED	Human-readable prompt displayed to the user by the agent runtime.
requestedSchema	Form mode only	A restricted JSON Schema object describing the fields the user must fill in. Maps 1:1 to the Structured Elicitation requestedSchema.

Note: A "url" mode (out-of-band browser interaction) is defined in and may be used in future revisions of this specification for authenticator types that require a browser ceremony (e.g., Passkeys in runtimes that cannot invoke the WebAuthn API natively).

Request Content Type for Intermediate Requests The initial Authorization Challenge Request MUST use application/x-www-form-urlencoded as required by . Intermediate requests — those that carry an auth_session obtained from a prior challenge response — MAY use application/json as the content type. This is consistent with , which explicitly permits intermediate requests to use a different format than the initial request.

Elicitation Sequencing The elicitations array typically contains one entry at a time. Because subsequent steps depend on prior user selections (e.g., choosing TOTP versus Passkey changes the next challenge), the authorization server issues each step's elicitation in a new Authorization Challenge Response after the preceding credential is submitted.

Clients Without Structured Elicitation Support For clients that do not support Structured Elicitation, the authorization server returns a standard OAuth error response per §5.2. The WWW-Authenticate response header per §5.2 is one example of how the error is surfaced at the HTTP level:

Runtime Bindings The elicitations array is a transport-agnostic FiPA extension. The agent runtime is responsible for translating each entry into its native interaction mechanism. This section defines bindings for known runtimes.

MCP Elicitation Binding When the agent runtime is MCP-based, the runtime (acting as the FiPA client) maps each elicitations entry directly to an elicitation/create params object per . The jsonrpc, id, and method fields are MCP transport framing — the params content is identical to the elicitations entry. The following example shows a form mode elicitation entry from the Authorization Challenge Response alongside the resulting elicitation/create call: FiPA elicitations entry (from Authorization Challenge Response): Resulting MCP elicitation/create call issued by the MCP server: MCP client response:

MCP Elicitation Flow Example | | | | | execute | | | | MCP tool | | | |-------------->| | | | | Authorization | | | | Request | | | |--------------------->| | | | | | | | Authorization | | | | Challenge Error | | | | + Elicitations | | | |<---------------------| | | | | | | | MCP Elicitation | | |<--------------| | | | | | | Input | | | |-------------->| | | | | Elicitation | | | | Response | | | |-------------->| | | | | Authorization | | | | Challenge Request | | | |--------------------->| | | | | | | | Authorization | | | | Challenge Error | | | | + Elicitations | | | |<---------------------| | | | | | | | ... (repeat as | | | | needed) | | | | | | | | Authorization | | | | Code Response | | | |<---------------------| | | | | | | | Token Request | | | |--------------------->| | | | | | | | Token Response | | | |<---------------------| | | | | ]]>

HTTP API Binding TODO: future section

Authorization Challenge Protocol

Authorization Challenge Response When the authorization server requires additional authentication, it returns an insufficient_authorization error response containing an elicitations array. Each entry in elicitations describes one structured challenge the agent runtime MUST present to the human user. The response includes the following parameters:

Parameter	Required	Description
error	REQUIRED	MUST be "insufficient_authorization".
auth_session	REQUIRED	Session identifier that MUST be included in all subsequent Authorization Challenge Requests for this context.
elicitations	REQUIRED	Array of elicitation objects. Each entry contains mode, message, and (for "form" mode) requestedSchema. See the Appendix for authenticator-specific schema examples.

", "elicitations": [ { "mode": "form", "message": "", "requestedSchema": { ... } } ] } ]]>

Authorization Challenge Request After collecting user input via Structured Elicitation, the agent runtime submits an Authorization Challenge Request to the authorization challenge endpoint.

Parameter	Required	Description
auth_session	REQUIRED	The session identifier from the preceding Authorization Challenge Response.
response	REQUIRED	An object whose fields match the requestedSchema advertised in the corresponding elicitations entry.

", "response": { ... } } ]]> On success, the authorization server issues an OAuth token bound to the completed auth_session, per .

Security Considerations TBD

IANA Considerations TBD

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. IETF OAuth Working Group n.d. Anthropic n.d. W3C n.d. Informative References OpenID Foundation n.d.

Appendix

Examples

Authenticator Selection When additional authentication is required, the first elicitation typically presents the available authenticators. The following examples show the FiPA wire format for authenticator selection. This specification defines elicitation schemas for two authenticator types: Passkey (WebAuthn) and Authenticator App (TOTP). Password authentication is outside the scope of this document. When multiple authenticators are supported, the authorization server returns a selection prompt: The agent submits the user's selection:

TOTP Challenge TOTP uses form mode: the challenge is a 6-digit numeric code, expressible as a plain string with pattern and length constraints. Authorization Challenge Response: Authorization Challenge Request: On success, the authorization server issues an OAuth token with the authenticated ACR value, per .

Passkey Challenge In a Third-Party AI Agent deployment, the client runtime is a product the implementer does not control. It supports standard Structured Elicitation form mode and URL mode but cannot be extended with custom format handling or WebAuthn API invocation. For Third-Party AI Agents, URL mode SHOULD be used to redirect the user to a browser-based WebAuthn flow. The out-of-band WebAuthn ceremony is outside the scope of this specification. For in-band Passkey support, a First-Party AI Agent deployment is required. The implementer controls the agent code and MAY implement custom elicitation handling, including native WebAuthn API invocation using the OS or platform FIDO2 APIs. The WebAuthn ceremony is performed in-band: no browser, no redirect.

WebAuthn Challenge Delivery This section defines how the authorization server delivers WebAuthn challenge parameters to the agent through Structured Elicitation form mode. TBD

Authorization Challenge Response TBD