Independent Submission M. Besozzi Internet-Draft TwoGenIdentity Intended status: Informational 3 April 2026 Expires: 5 October 2026 OAuth 2.0 Agents Native Authorization via Structured Elicitation draft-embesozzi-oauth-agent-native-authorization-00 Abstract This document defines a Structured Elicitation extension to the OAuth 2.0 First-Party Applications (FiPA) specification [FiPA], 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 [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 This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://embesozzi.github.io/draft-embesozzi-oauth-agent-native- authorization/draft-embesozzi-oauth-agent-native-authorization.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-embesozzi-oauth-agent-native- authorization/. Source for this draft and an issue tracker can be found at https://github.com/embesozzi/draft-embesozzi-oauth-agent-native- authorization. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Besozzi Expires 5 October 2026 [Page 1] Internet-Draft Agent Native Authorization April 2026 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 5 October 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Human-to-Agent (H2A) Communication Model . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 4. Elicitation Extension . . . . . . . . . . . . . . . . . . . . 5 4.1. Response Format . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Request Content Type for Intermediate Requests . . . 6 4.1.2. Elicitation Sequencing . . . . . . . . . . . . . . . 6 4.1.3. Clients Without Structured Elicitation Support . . . 7 4.2. Runtime Bindings . . . . . . . . . . . . . . . . . . . . 7 4.2.1. MCP Elicitation Binding . . . . . . . . . . . . . . . 7 4.2.2. HTTP API Binding . . . . . . . . . . . . . . . . . . 11 5. Authorization Challenge Protocol . . . . . . . . . . . . . . 11 5.1. Authorization Challenge Response . . . . . . . . . . . . 11 5.2. Authorization Challenge Request . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 14 Besozzi Expires 5 October 2026 [Page 2] Internet-Draft Agent Native Authorization April 2026 A.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14 A.1.1. Authenticator Selection . . . . . . . . . . . . . . . 14 A.1.2. TOTP Challenge . . . . . . . . . . . . . . . . . . . 15 A.1.3. Passkey Challenge . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction 1.1. 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 [FiPA] 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 [MCP-Elicitation] as the normative reference implementation. 1.2. 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. Besozzi Expires 5 October 2026 [Page 3] Internet-Draft Agent Native Authorization April 2026 2. 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 [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.1. Terminology This document uses terminology defined in [RFC6749], [FiPA], and [MCP-Elicitation]. The following terms are used as defined: * *Authorization Server (AS):* As defined in [RFC6749]. * *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 [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. Besozzi Expires 5 October 2026 [Page 4] Internet-Draft Agent Native Authorization April 2026 3. Protocol Overview This extension operates within the FiPA challenge/response cycle defined in [FiPA]. A FiPA authorization request that requires additional authentication receives an Authorization Challenge Response: HTTP/1.1 400 Bad Request Content-Type: application/json { "error": "insufficient_authorization", "auth_session": "sess_abc123" } 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. 4. Elicitation Extension 4.1. 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: Besozzi Expires 5 October 2026 [Page 5] Internet-Draft Agent Native Authorization April 2026 +=================+==========+======================================+ | 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 | A restricted JSON Schema | | | mode | object describing the fields | | | only | the user must fill in. Maps | | | | 1:1 to the Structured | | | | Elicitation requestedSchema. | +-----------------+----------+--------------------------------------+ Table 1 Note: A "url" mode (out-of-band browser interaction) is defined in [MCP-Elicitation] 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). 4.1.1. Request Content Type for Intermediate Requests The initial Authorization Challenge Request MUST use application/x- www-form-urlencoded as required by [FiPA]. 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 [FiPA], which explicitly permits intermediate requests to use a different format than the initial request. 4.1.2. 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. Besozzi Expires 5 October 2026 [Page 6] Internet-Draft Agent Native Authorization April 2026 4.1.3. Clients Without Structured Elicitation Support For clients that do not support Structured Elicitation, the authorization server returns a standard OAuth error response per [RFC6749] §5.2. The WWW-Authenticate response header per [RFC6749] §5.2 is one example of how the error is surfaced at the HTTP level: WWW-Authenticate: Bearer realm="authorization-server", error="insufficient_scope", auth_session="sess_abc123" 4.2. 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. 4.2.1. 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 [MCP-Elicitation]. 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): Besozzi Expires 5 October 2026 [Page 7] Internet-Draft Agent Native Authorization April 2026 { "mode": "form", "message": "Additional verification is required. Select your authentication method.", "requestedSchema": { "type": "object", "properties": { "authenticator": { "type": "string", "title": "Authentication Method", "oneOf": [ { "const": "totp", "title": "Authenticator App (TOTP)" }, { "const": "passkey", "title": "Passkey" } ] } }, "required": ["authenticator"] } } Resulting MCP elicitation/create call issued by the MCP server: { "jsonrpc": "2.0", "id": "elicit-1", "method": "elicitation/create", "params": { "mode": "form", "message": "Additional verification is required. Select your authentication method.", "requestedSchema": { "type": "object", "properties": { "authenticator": { "type": "string", "title": "Authentication Method", "oneOf": [ { "const": "totp", "title": "Authenticator App (TOTP)" }, { "const": "passkey", "title": "Passkey" } ] } }, "required": ["authenticator"] } } } MCP client response: Besozzi Expires 5 October 2026 [Page 8] Internet-Draft Agent Native Authorization April 2026 { "jsonrpc": "2.0", "id": "elicit-1", "result": { "action": "accept", "content": { "authenticator": "totp" } } } 4.2.1.1. MCP Elicitation Flow Example Besozzi Expires 5 October 2026 [Page 9] Internet-Draft Agent Native Authorization April 2026 Human AI Agent MCP Server Authorization Server | | | | | Prompt | | | |-------------->| | | | | 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 | | | |<---------------------| | | | | Besozzi Expires 5 October 2026 [Page 10] Internet-Draft Agent Native Authorization April 2026 4.2.2. HTTP API Binding TODO: future section 5. Authorization Challenge Protocol 5.1. 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. | +--------------+----------+-------------------------------------+ Table 2 Besozzi Expires 5 October 2026 [Page 11] Internet-Draft Agent Native Authorization April 2026 HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-store { "error": "insufficient_authorization", "auth_session": "", "elicitations": [ { "mode": "form", "message": "", "requestedSchema": { ... } } ] } 5.2. 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. | +--------------+----------+-----------------------------------+ Table 3 POST /as/authorization.oauth2 Content-Type: application/json { "auth_session": "", "response": { ... } } On success, the authorization server issues an OAuth token bound to the completed auth_session, per [FiPA]. Besozzi Expires 5 October 2026 [Page 12] Internet-Draft Agent Native Authorization April 2026 6. Security Considerations TBD 7. IANA Considerations TBD 8. References 8.1. Normative References [FiPA] IETF OAuth Working Group, "OAuth 2.0 First-Party Applications", n.d., . [MCP-Elicitation] Anthropic, "Model Context Protocol Specification — Elicitation", n.d., . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, . [WebAuthn] W3C, "Web Authentication: An API for accessing Public Key Credentials, Level 3", n.d., . 8.2. Informative References Besozzi Expires 5 October 2026 [Page 13] Internet-Draft Agent Native Authorization April 2026 [EAP-ACR] OpenID Foundation, "OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0", n.d., . Appendix A. Appendix A.1. Examples A.1.1. 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: Besozzi Expires 5 October 2026 [Page 14] Internet-Draft Agent Native Authorization April 2026 HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-store { "error": "insufficient_authorization", "auth_session": "sess_abc123", "elicitations": [ { "mode": "form", "message": "Additional verification is required. Select your authentication method.", "requestedSchema": { "type": "object", "properties": { "authenticator": { "type": "string", "title": "Authentication Method", "oneOf": [ { "const": "totp", "title": "Authenticator App (TOTP)" }, { "const": "passkey", "title": "Passkey" } ] } }, "required": ["authenticator"] } } ] } The agent submits the user's selection: POST /as/authorization.oauth2 Content-Type: application/json { "auth_session": "sess_abc123", "response": { "authenticator": "totp" } } A.1.2. 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: Besozzi Expires 5 October 2026 [Page 15] Internet-Draft Agent Native Authorization April 2026 HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-store { "error": "insufficient_authorization", "auth_session": "sess_abc123", "elicitations": [ { "mode": "form", "message": "Enter the 6-digit code from your Authenticator App.", "requestedSchema": { "type": "object", "properties": { "otp": { "type": "string", "title": "One-Time Password", "minLength": 6, "maxLength": 6, "pattern": "^[0-9]{6}$" } }, "required": ["otp"] } } ] } Authorization Challenge Request: POST /as/authorization.oauth2 Content-Type: application/json { "auth_session": "sess_abc123", "response": { "otp": "847291" } } On success, the authorization server issues an OAuth token with the authenticated ACR value, per [FiPA]. A.1.3. 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. Besozzi Expires 5 October 2026 [Page 16] Internet-Draft Agent Native Authorization April 2026 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. A.1.3.1. WebAuthn Challenge Delivery This section defines how the authorization server delivers WebAuthn challenge parameters to the agent through Structured Elicitation form mode. TBD A.1.3.2. Authorization Challenge Response TBD Author's Address Martin Besozzi TwoGenIdentity Email: embesozzi@twogenidentity.com Besozzi Expires 5 October 2026 [Page 17]