Individual submission M. Liu Internet-Draft China Mobile Intended status: Standards Track 2 November 2026 Expires: 6 May 2027 Agent Action Confirmation Protocol (AACP) draft-liu-agent-action-confirmation-00 Abstract AI agents invoke operations with side effects: writes to resources, creation of durable records, financial transactions, and delegated actions on remote systems. Existing requirement documents in the agentproto working group establish that such operations require confirmation by the human user, that this confirmation must occur outside of LLM prompt inference, and that in multi-agent delegation the receiving agent must be able to verify that a presented confirmation actually originated from the user and is not fabricated by an intermediate agent. No document in the current document set defines a protocol, message format, or evidence format that satisfies these requirements. This document defines the Agent Action Confirmation Protocol (AACP): an action descriptor format derived from OAuth 2.0 Rich Authorization Requests (RFC 9396), a confirmation request format, a signed confirmation evidence format, and verifier- side processing rules with a distinct-outcome failure model. The design is transport-neutral and profiled here for JSON over HTTP with JWS signatures; a CBOR/COSE mapping is defined. A requirement traceability matrix maps each mechanism to its source requirement in the agentproto document set. This document is informed by, and positions itself relative to, two prior individual submissions that addressed user confirmation of agent actions and have since expired: CHEQ [I-D.rosenberg-aiproto-cheq] and the Agent Operation Authorization framework [I-D.liu-agent-operation-authorization]. The differences are summarized in Section 1.4. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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/. Liu Expires 6 May 2027 [Page 1] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 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 6 May 2027. 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background and Motivation . . . . . . . . . . . . . . . . 3 1.2. Relationship to agentproto Requirement Documents . . . . 5 1.3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 7 1.4. Relationship to Prior Individual Submissions . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 10 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. The Confirmation Service . . . . . . . . . . . . . . . . 11 4.3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Confirmation Flows . . . . . . . . . . . . . . . . . . . 12 5. Action Descriptor . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Fields . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Rendering Requirements . . . . . . . . . . . . . . . . . 14 5.3. Action Digest Computation . . . . . . . . . . . . . . . . 15 5.4. CDDL Definition . . . . . . . . . . . . . . . . . . . . . 15 6. Confirmation Request . . . . . . . . . . . . . . . . . . . . 15 7. Confirmation Evidence . . . . . . . . . . . . . . . . . . . . 16 7.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. Signature and Canonicalization . . . . . . . . . . . . . 17 7.3. Authentication Context . . . . . . . . . . . . . . . . . 18 7.4. Binding Rules . . . . . . . . . . . . . . . . . . . . . . 18 7.5. Lifetime and Freshness . . . . . . . . . . . . . . . . . 19 8. Verification Procedure . . . . . . . . . . . . . . . . . . . 19 Liu Expires 6 May 2027 [Page 2] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 8.1. Verification Steps . . . . . . . . . . . . . . . . . . . 19 8.2. Outcome Matrix and Error Codes . . . . . . . . . . . . . 20 8.3. Replay Prevention . . . . . . . . . . . . . . . . . . . . 22 9. Multi-Agent Confirmation . . . . . . . . . . . . . . . . . . 22 9.1. Delegated Flow . . . . . . . . . . . . . . . . . . . . . 22 9.2. Handoff Chain Binding . . . . . . . . . . . . . . . . . . 22 9.3. Denied, Unobtainable, and Stale Are Different Facts . . . 23 10. API Integration . . . . . . . . . . . . . . . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 11.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 24 11.2. Residual Risks . . . . . . . . . . . . . . . . . . . . . 25 11.3. Algorithm Agility . . . . . . . . . . . . . . . . . . . 26 11.4. Key Management . . . . . . . . . . . . . . . . . . . . . 26 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 13.1. Media Types . . . . . . . . . . . . . . . . . . . . . . 27 13.2. Confirmation Outcome Values Registry . . . . . . . . . . 27 13.3. Error Code Allocation . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 14.1. Normative References . . . . . . . . . . . . . . . . . . 27 14.2. Informative References . . . . . . . . . . . . . . . . . 28 Appendix A. Complete CDDL Definition . . . . . . . . . . . . . . 31 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 32 B.1. Action Descriptor (flight booking) . . . . . . . . . . . 32 B.2. Confirmation Request . . . . . . . . . . . . . . . . . . 33 B.3. Confirmation Evidence (payload before JCS and signing) . 33 B.4. Denied Evidence . . . . . . . . . . . . . . . . . . . . . 33 B.5. Unobtainable Status . . . . . . . . . . . . . . . . . . . 33 Appendix C. Requirement Traceability Matrix . . . . . . . . . . 33 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 35 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction 1.1. Background and Motivation AI agents are software applications that utilize Large Language Models (LLMs) to perform tasks, and they invoke operations with side effects on external systems: creating bookings, updating records, initiating payments, executing delegated administrative actions. Two properties of current agent architectures make unconfirmed side- effecting operations hazardous: 1. Fallible inference. An agent may invoke the wrong operation, or the right operation with wrong parameters, as a direct consequence of model error. Read operations are recoverable; side-effecting operations may not be. Liu Expires 6 May 2027 [Page 3] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 2. Untrustworthy intermediaries. In multi-agent delegation, a chain of agents conveys context and instructions between the user and the agent that ultimately acts. An intermediate agent may fabricate the claim "the user approved this" — whether through hallucination or compromise — and nothing in current agent communication protocols lets the acting agent distinguish a real user decision from a fabricated one. The agentproto working group's requirement documents address both properties but deliberately stop at the requirements level. [I-D.rosenberg-agentproto-usecases] Section 3.2.3 requires that confirmation for side-effecting operations happen "programatically, outside of the LLM prompt inference", that APIs be annotated with which operations require confirmation, and that the annotation carry user-visible names and descriptions of the attributes that require confirmation, together with their mapping into the operation's JSON payload. Section 3.3.6 extends the requirement to inter-agent communication: "How can the invoked AI agent trust that the confirmation actually came from the end user, and is not instead a hallucination generated by the invoking AI Agent? This will also require protocol machinery to provider cryptographic assurances." The security-focused documents in the document set define requirement models for the evidence that would answer this question, while explicitly declining to define the evidence format. [I-D.bu-agentproto-security-principal-binding] separates claims including "action evidence" (claim C-005) from other security- relevant claims, and defines row-outcome and dependency-closure rules so that a verification result cannot be stronger than its inputs. [I-D.he-agentproto-verifier-evidence] requires that a verification result report whether a check has been "exercised into its declared rejecting and unverifiable outcomes"; that document "defines no wire format, encoding, token, claim vocabulary, test harness, or registry". [I-D.konda-agentproto-evaluation-state] requires that the facts "the input was established and evaluated negatively" and "the input could not be established at all" remain distinct across a protocol boundary, and notes that its test cases have "a machine- readable form published separately". [I-D.wadkins-agentproto-action-determinability] requires that a claimed agent transition remain "independently determinable after the original interaction has ended". This document defines the missing piece: a wire-level protocol and evidence format that satisfies those requirements. It is deliberately positioned as a profile-ready building block rather than a new architecture: AACP defines what must be confirmed, how the confirmation is bound to the action, and how a verifier processes and Liu Expires 6 May 2027 [Page 4] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 reports the result. It does not define new transport, discovery, or agent identity mechanisms, and composes with the candidate transports under discussion in the working group. 1.2. Relationship to agentproto Requirement Documents This document takes requirements from, and is intended to be citable by, the following documents in the working group's document set: +=================================================+=================+ | Source document |Requirement | | |taken | +=================================================+=================+ | [I-D.rosenberg-agentproto-usecases] |Programmatic | | |confirmation | | |outside LLM | | |inference; API | | |annotation of | | |confirmation | | |requirements; | | |user-visible | | |attribute | | |mapping (Sec | | |3.2.3); | | |cryptographic | | |assurance that | | |confirmation | | |originates from | | |the user in | | |inter-agent | | |flows (Sec | | |3.3.6) | +-------------------------------------------------+-----------------+ | [I-D.bu-agentproto-security-principal-binding] |Claim separation | | |(C-005 action | | |evidence, C-007 | | |evidence | | |provenance, | | |C-008 | | |freshness); row- | | |outcome | | |semantics; | | |failure handling | | |(C-009) | +-------------------------------------------------+-----------------+ | [I-D.he-agentproto-verifier-evidence] |Exercise | | |evidence: a | | |result must | Liu Expires 6 May 2027 [Page 5] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 | |report whether | | |checks have been | | |exercised into | | |rejecting and | | |unverifiable | | |outcomes | +-------------------------------------------------+-----------------+ | [I-D.konda-agentproto-evaluation-state] |Evaluation state | | |preservation: | | |denied vs | | |unobtainable vs | | |stale are | | |distinct facts | | |with distinct | | |protocol | | |outcomes | +-------------------------------------------------+-----------------+ | [I-D.wadkins-agentproto-action-determinability] |Post-session | | |determinability: | | |evidence remains | | |verifiable after | | |sessions, | | |credentials, and | | |agent instances | | |are gone | +-------------------------------------------------+-----------------+ | [I-D.agentic-ai-usecases-requirements] |CMN-12: a | | |participant must | | |be able to | | |verify that a | | |change is | | |authorized at | | |the time it | | |happens, and | | |must be able to | | |determine | | |whether a check | | |failed or could | | |not be completed | +-------------------------------------------------+-----------------+ | [I-D.srivastava-agentproto-handoff-context] |Handoff chain: | | |offers named by | | |hash (chain | | |binding of | | |confirmation to | | |delegation path) | +-------------------------------------------------+-----------------+ | [I-D.okutomi-session-bound-agent-identity] |Context | Liu Expires 6 May 2027 [Page 6] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 | |diversion: | | |evidence must | | |not be | | |acceptable for a | | |different actor, | | |task, or | | |authority | | |boundary | +-------------------------------------------------+-----------------+ | [I-D.howe-agentproto-contact-center-usecases] |Cross-channel | | |confirmation and | | |dialog | | |resumption | | |semantics for | | |out-of-band | | |confirmation | | |(CC3-1, CC3-4) | +-------------------------------------------------+-----------------+ Table 1 Appendix C contains the full traceability matrix from mechanism to requirement. 1.3. Scope and Non-Goals In scope: * A JSON [RFC8259] action descriptor format, derived from and aligned with the "authorization_details" structure of OAuth 2.0 Rich Authorization Requests [RFC9396], extended with confirmation- specific metadata. * A confirmation request format and a signed confirmation evidence format, including binding rules, freshness rules, and an authentication context. * Verifier-side processing rules with a distinct-outcome failure model, suitable for enforcement at API gateways and at acting agents. * A CBOR [RFC8949] / COSE [RFC9052] mapping. Out of scope (non-goals): * Agent discovery, routing, session establishment, or transport selection. AACP rides on existing or emerging agent communication protocols and API invocation mechanisms. Liu Expires 6 May 2027 [Page 7] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 * Agent identity, agent-to-agent authentication, or token issuance. AACP binds confirmations to actions and users; it presumes agent authentication is solved by the surrounding protocol, and requires only that identifiers be nameable. * How users authenticate to the Confirmation Service. AACP carries an authentication context describing how the user authenticated, not the authentication mechanism itself. * Prompt injection defenses in general. AACP reduces the blast radius of prompt injection by moving irreversible decisions out of LLM inference, but does not detect or prevent injection attacks. * General-purpose audit systems and transparency services. AACP evidence is designed to be referenceable by such systems (e.g., by digest), not to replace them. The scope boundary above is aligned with the agentproto working group charter [CHARTER]. The charter places "the design of human to agent user interfaces, client application UX, or the rendering of agent outputs on end-user devices" and "audit data structures and their production, validation, or consumption" outside the working group's scope. AACP addresses neither: its rendering requirements are constraints on API metadata and on programmatic processing of that metadata (which fields must be confirmed and how their values are named for display), not user interface design; and its evidence is an authorization input, not an audit data structure. The distinct- outcome signals of Section 8.2 are protocol errors, which the charter places in scope. 1.4. Relationship to Prior Individual Submissions Two prior individual Internet-Drafts addressed user confirmation of agent actions and have since expired without renewal: CHEQ [I-D.rosenberg-aiproto-cheq] proposed a signed object memorializing a human decision, with collection outside the LLM, embeddable in MCP, A2A, and N-ACT. Its core concern — that hallucinated decisions must not produce unwanted actions, and that a signature by an identity provider authenticating the user is the assurance mechanism — is shared by AACP. AACP differs in three ways. First, CHEQ is transport-embedded but verifier-implicit: it does not define a verifier-side processing model, so the question of what a relying party does with a malformed, stale, or redirected CHEQ is left open; AACP's row-outcome model (Section 8) makes that processing normative. Second, CHEQ was written before the agentproto document set existed and therefore does not trace to its requirements; AACP aligns with the claim separation (C-005, C-007, C-008), row-outcome, Liu Expires 6 May 2027 [Page 8] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 and dependency-closure models of [I-D.bu-agentproto-security-principal-binding], the exercise requirements of [I-D.he-agentproto-verifier-evidence], and the evaluation-state requirements of [I-D.konda-agentproto-evaluation-state]. Third, CHEQ couples confirmation with privacy-protected information collection; AACP separates concerns and defines only the confirmation exchange. The Agent Operation Authorization framework [I-D.liu-agent-operation-authorization] proposed a two-phase JWT model: an agent_operation_proposal conveyed via OAuth Pushed Authorization Requests, and an Agent Operation Authorization Token recording confirmed authorization. Its insight — that a structured operation proposal, presented to the user through the authorization server rather than through the agent, prevents unauthorized or hallucinated actions — is likewise shared. AACP differs in that it is not bound to the OAuth authorization code/PAR flow: it defines an independent confirmation exchange that composes with agent-to-agent delegation (Section 9), where the user is not the OAuth resource owner vis-a-vis the acting agent, and where the delegated flow's hallucination problem (Section 3.3.6 of [I-D.rosenberg-agentproto-usecases]) is not solved by a token issued to the agent. AACP's evidence is verified at action time against the operation's parameters (action digest), not presented as a bearer credential. The user-mediated credential delivery proposal [I-D.emerson-oauth-user-mediated-delivery], currently active in the OAuth working group's problem space, includes per-action confirmation by introspection with a user-verified authenticator. AACP is complementary: that work places authorization decisions and credential delivery in the user's trusted context at the OAuth grant layer; AACP defines the confirmation object, its binding rules, and its verification semantics for the agent communication layer, and can carry evidence produced by such a flow in its auth-context. 2. Terminology The terms "agent", "user", and "agent communication protocol" are used as in [I-D.rosenberg-agentproto-usecases]. Acting Agent (AA) The agent that will invoke a side-effecting operation (an API call or a delegated sub-task) and that must present evidence that the operation was confirmed. In the terminology of [I-D.rosenberg-agentproto-usecases], typically the "invoked agent"; in tool-calling deployments, the agent holding the tool. Requesting Agent (RA) The agent in whose dialog with the user the Liu Expires 6 May 2027 [Page 9] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 confirmation is collected; typically the "invoking agent". In single-agent flows, RA and AA are the same entity. Confirming User (U) The human whose decision the evidence records. Confirmation Service (CS) The component that renders an action descriptor to the user through a non-LLM programmatic path, collects the user's decision, and signs the confirmation evidence. The CS is the trust anchor of this protocol. Action Descriptor (AD) The typed, self-contained description of the operation to be confirmed, as defined in Section 5. Confirmation Request (CR) The message from AA to CS asking for confirmation of a specific action, as defined in Section 6. Confirmation Evidence (CE) The signed record of the user's decision, as defined in Section 7. Verification The procedure by which a verifier checks a CE against the operation it accompanies (Section 8). Row outcome As in [I-D.bu-agentproto-security-principal-binding]: the verified status of a single claim row after verification processing, distinct from specification or implementation status. 3. Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 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. 4. Architecture 4.1. Roles AACP involves four roles: U (Confirming User) — CS (Confirmation Service) — AA (Acting Agent) — [optional RA (Requesting Agent)] — target operation The Acting Agent constructs the Action Descriptor and the Confirmation Request. The Confirmation Service renders the descriptor to the user, obtains the decision, and produces signed Confirmation Evidence. The Acting Agent (or the API it invokes) verifies the evidence at action time; any later verifier can re- verify the evidence after the fact. Liu Expires 6 May 2027 [Page 10] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 The Confirmation Service is the only role that holds a signature key in the base protocol. This is a deliberate design decision: it isolates the trust question "did the user really decide this?" into a component whose key management, user interface, and authentication quality can be audited independently of any agent implementation. The CS is frequently a component of the user's client application, the enterprise's authorization infrastructure, or a dedicated confirmation application on a user device. 4.2. The Confirmation Service A conforming Confirmation Service: * MUST render confirmation requests to the user through a programmatic interface, not by embedding the request in an LLM prompt. This is the requirement of [I-D.rosenberg-agentproto-usecases] Section 3.2.3. A CS that forwards the confirmation decision through an LLM inference step does not conform. * MUST render every parameter marked "confirm": true in the action descriptor, with its user-visible label, before presenting the decision control. * MUST sign evidence with a key bound to an identifier that verifiers can discover and validate (Section 7.2). * MUST NOT sign evidence for a decision it did not itself render and collect. * SHOULD bind the rendering it produced to the evidence it signs (via the rendering digest, Section 7.4). * MUST maintain replay state for the lifetime of each request (Section 8.3). 4.3. Trust Model The trust model answers three questions: 1. Does the verifier trust the CS to have actually interacted with the user? Established by CS key validation and by local policy (a verifier may accept a restricted set of CSes, e.g., those operated by the same enterprise as the verifier). Liu Expires 6 May 2027 [Page 11] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 2. Does the evidence concern THIS action? Established by the action digest: the verifier recomputes the digest over the operation it is about to execute. A CE that confirms a different action, or an action with different parameters, will not match (Section 7.4). 3. Is the evidence current? Established by the challenge (AA- generated nonce), the confirmed-at time, and the lifetime (Section 7.5). A fourth property, aligned with [I-D.okutomi-session-bound-agent-identity], is audience binding in delegated flows: a CE names the acting agent for which it was issued, so evidence obtained for one delegation is not acceptable for another (Section 9). The model deliberately does NOT require the verifier to trust the requesting agent, the agent communication protocol, or any intermediate agent. This is the property that answers the hallucination concern of [I-D.rosenberg-agentproto-usecases] Section 3.3.6: a fabricated confirmation cannot be produced without the CS key, and a real confirmation cannot be redirected to a different action or actor. 4.4. Confirmation Flows Three flows are supported. Variant A — Tool call, single agent (RA == AA): 1. AA determines the operation requires confirmation (from API metadata, Section 10). 2. AA constructs the AD (Section 5) and CR (Section 6). 3. CS renders, collects the decision, signs the CE. 4. AA invokes the operation presenting the CE. 5. The API (or AA's enforcement point) verifies per Section 8. Variant B — Delegated action (RA != AA): 1. AA (the invoked agent) constructs the AD and CR for its own operation, including its own challenge and itself as audience. 2. AA sends the CR to RA over the agent communication protocol. 3. RA relays the CR to its CS. RA MUST NOT alter the AD or challenge; the digest and challenge make alteration detectable. 4. CS renders to the user (RA's user is the confirming user if the delegation carries user authority; see Section 9). 5. CS signs the CE; RA relays it back to AA. 6. AA verifies the CE (Section 8) before executing. Liu Expires 6 May 2027 [Page 12] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 Variant C — Out-of-band confirmation: When the user is not reachable on the current channel, the CR carries channel requirements (Section 6); the CS delivers the confirmation prompt through a pre-registered side channel (device push, SMS, email), collects the decision out of band, and the result is returned asynchronously. This variant addresses the reconnection and channel- negotiation requirements discussed in [I-D.feng-agentproto-session-requirements] and the resumption semantics of [I-D.howe-agentproto-contact-center-usecases] (CC3-1, CC3-4): an unobtainable confirmation is reported as a status outcome, not as a denial (Section 9.3). 5. Action Descriptor The Action Descriptor is the object the user actually confirms. It is a JSON object conforming to the "authorization_details" entry format of [RFC9396] Section 2, with the extensions defined in this section. Reuse of the RAR structure is deliberate: it gives the protocol a field-tested typed-descriptor model, an existing body of deployment practice in open banking, and a documented set of pitfalls (type design, consent-screen sanitization) that this profile inherits and addresses. 5.1. Fields type (string, REQUIRED) An identifier for the action type, as in [RFC9396] Section 2.1. The value determines the allowable contents of the descriptor. For interoperability across domains, the value SHOULD be a URI under the control of the API provider, following the collision-resistant namespace guidance of [RFC9396]. actions (array of strings, REQUIRED) The kinds of action requested, e.g., "initiate", "update", "cancel". locations (array of strings, OPTIONAL) The resource servers or endpoints where the action will be executed, as in [RFC9396] Section 2.2. parameters (object, OPTIONAL) A map from field name to a parameter object: value (any, REQUIRED) The actual value for the operation invocation. confirm (boolean, OPTIONAL, default false) If true, this parameter MUST be rendered to the user as part of the confirmation. API metadata determines which parameters carry confirm=true (Section 10). render (object, OPTIONAL) User-visible rendering metadata for the Liu Expires 6 May 2027 [Page 13] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 parameter: "label" (a short human-readable name), "value-label" (a pre-formatted human rendering of the value), "format" (a rendering hint such as "currency" or "date"), and "sensitive" (if true, verifiers and logs SHOULD mask this parameter's value, Section 12). effect (string, OPTIONAL) One of "create", "update", "delete", "transfer", "communication". Classifies the effect class of the operation; used by policy. This field operationalizes the distinction between an action and its effect identified by [I-D.wadkins-agentproto-action-determinability]. reversible (boolean, OPTIONAL) Whether the operation's effect can be undone by the same authority. When false or absent, implementations SHOULD treat the operation as irreversible for policy purposes. expires (time, OPTIONAL) RFC 3339 timestamp after which the descriptor itself is stale and a new confirmation is required (e.g., fare validity). Further fields MAY be added by action type definitions, as in [RFC9396]. Unknown fields MUST be preserved by intermediaries and included in digest computations. 5.2. Rendering Requirements A conforming renderer (the CS) MUST construct the user-visible confirmation from the AD as follows: * Every parameter with confirm=true MUST be displayed, with its render.label (or the field name if no label), and either its render.value-label or a programmatic formatting of value under render.format. * The rendering set — the ordered sequence of (field, label, rendered value) pairs actually displayed — is the input to the rendering digest (Section 7.4). * Rendering MUST occur in a non-LLM programmatic component. The AD, its labels, and its values are untrusted display input: the renderer MUST treat them as data, not markup, and MUST NOT interpret formatting, links, or instructions within them. This mirrors the consent-screen sanitization requirement noted in [RFC9396] Section 2.1 and the rendering requirements of [I-D.rosenberg-agentproto-usecases] Section 3.2.3. * The renderer MUST present an explicit accept and reject control, and MUST NOT default to acceptance. Liu Expires 6 May 2027 [Page 14] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 5.3. Action Digest Computation The action digest binds evidence to the exact action. To compute: 1. Construct the AD as a JSON object. The object MUST conform to I-JSON [RFC7493] (no duplicate member names, no numbers that lose precision). 2. Canonicalize using the JSON Canonicalization Scheme [RFC8785] (JCS). 3. Compute SHA-256 [FIPS180-4] over the canonical form. The digest is carried in binary in CBOR and base64url-encoded without padding in JSON. Verifiers MUST recompute this digest over the operation they are asked to execute. To make recomputation deterministic, the operation-to-AD mapping for each action type MUST be defined by the action type's specification (how each API request field maps into AD parameters). Section 10 defines how API metadata carries this mapping. 5.4. CDDL Definition The CDDL [RFC8610] definition of the action descriptor (JSON form): ; See Appendix A for the complete grammar aacp-action-descriptor = { type: uri actions: [1* text] ? locations: [1* uri] ? parameters: { * text => aacp-parameter } ? effect: aacp-effect ? reversible: bool ? expires: time * $$aacp-ad-extension } aacp-parameter = { value: any ? confirm: bool ? render: { ? label: text ? value-label: text ? format: text ? sensitive: bool } } aacp-effect = "create" / "update" / "delete" / "transfer" / "communication" 6. Confirmation Request The Confirmation Request is constructed by the Acting Agent. { "v": 1, "request-id": "", "action-digest": "", "challenge": "", "lifetime": 300, "audience": "", "subject": "", ? "channel": { "min-loa": 2, "modes": ["device-push", "sms"] }, ? "handoff": [ "" ], ? "rendering-hint": { ... } } Semantics: request-id Unique identifier for this confirmation request, Liu Expires 6 May 2027 [Page 15] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 generated as a UUID [RFC9562]. Used for replay tracking (Section 8.3). action-digest The digest defined in Section 5.3. The CR SHOULD also carry the full AD so the CS can render without an additional round-trip; the digest is authoritative. challenge AA-generated random value, at least 128 bits. The CS MUST include it in the signed evidence. This gives the AA a freshness proof it controls: evidence for a stale or transplanted challenge is detectable without any shared state between AA and CS. lifetime Maximum age, in seconds, of an acceptable confirmation measured from confirmed-at. audience The identifier of the Acting Agent for which this evidence is valid. Prevents context diversion per [I-D.okutomi-session-bound-agent-identity]: evidence issued for one delegation must not be usable for another. subject The user whose confirmation is sought, when known to AA. Binding of user identifiers is out of scope (Section 1.3), but the field MUST be carried into the evidence when present. channel Channel requirements for Variant C: minimum level of assurance and acceptable out-of-band modes. handoff Digests referencing the signed handoff offers through which the task reached this agent, when the action flows from a delegation chain [I-D.srivastava-agentproto-handoff-context]. See Section 9.2. 7. Confirmation Evidence 7.1. Structure The Confirmation Evidence records the user's decision: { "v": 1, "request-id": "", "action-digest": "", "challenge": "", "decision": "confirmed" / "denied", "audience": "", ? "subject": "", "confirmed-at": "", "auth-context": { "method": "", "loa": , ? "as": "" }, ? "rendering-digest": "", ? "handoff": [ "" ], ? "extensions": { ... } } decision "confirmed" or "denied". Both are signed. A denied Liu Expires 6 May 2027 [Page 16] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 decision MUST produce evidence, not silence: preserving negative outcomes is the exercise requirement of [I-D.he-agentproto-verifier-evidence] and the evaluation-state requirement of [I-D.konda-agentproto-evaluation-state]. Absence of evidence, in contrast, means no collection was attempted or completed, and is reported by the separate status object of Section 9.3. auth-context How the user authenticated to the CS at confirmation time: "method" (e.g., "passkey", "device-unlock", "knowledge- proof", "oauth-session"), "loa" (a coarse level of assurance, 0-5, scale defined by deployment policy), and optionally "as" (the identity of the authorization server when the CS operates as part of an OAuth deployment). This carries the authentication- assurance notion discussed in [I-D.rosenberg-agentproto-usecases] Section 3.2.2.2: verifiers can enforce that irreversible actions require, e.g., a fresh device authentication rather than a remembered session. rendering-digest SHA-256 over the JCS-canonicalized rendering set actually displayed (Section 5.2). Binds "what the user saw" to the signed record, enabling a verifier to check that the fields requiring confirmation were actually exercised (Appendix C, HE-1). 7.2. Signature and Canonicalization The CE is a JWS [RFC7515] with compact serialization: * Payload: the UTF-8 JCS [RFC8785] canonicalization of the CE JSON object. JCS canonicalization makes the signature deterministic across JSON serializers. * Signing algorithms: ES256 or EdDSA (Ed25519) [RFC8032] MUST be supported; RS256 MAY be supported. Algorithms MUST NOT be negotiated by the signer; the CS key's registered algorithm set is authoritative. * The "kid" header parameter identifies the CS key; verifiers resolve it through the CS's published key set (e.g., a JWK Set at a well-known location, or enterprise key distribution). Key discovery is deployment profile; this document requires only that a verifier can resolve a CS key to a CS identifier and check its freshness. * Detached payload (RFC 7515 Appendix F) MAY be used when the CE is conveyed alongside the already-known CR. CBOR mapping: Appendix A defines the CBOR form; signatures in the CBOR profile use COSE_Sign1 [RFC9052] with the same payload semantics. Liu Expires 6 May 2027 [Page 17] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 Key rotation: a CS MUST overlap old and new keys for at least the maximum evidence lifetime it issues; verifiers MUST accept keys valid at confirmed-at time, not only at verification time, to preserve post-session verifiability (the [I-D.wadkins-agentproto-action-determinability] requirement). 7.3. Authentication Context The auth-context is an honest report by the CS of how the user authenticated when the decision was collected. It is not a proof of authentication; it is a claim by the CS, covered by the CS signature. Verifiers apply policy to it: * An operation classified irreversible by policy SHOULD require a fresh method (device authentication, passkey with user verification) rather than a carried session. * A verifier MUST NOT infer more assurance than the auth-context states: a "knowledge-proof" method with loa 1 records exactly that, and policy for high-value actions may reject it. This mirrors the verifier-side acceptance discipline of [I-D.okutomi-session-bound-agent-identity]: what is accepted is what was actually verified, no more. 7.4. Binding Rules A CE is bound to: 1. The action, by action-digest. A verifier recomputes the digest over the operation at hand (Section 8.1, step 3). Mismatch invalidates the evidence for that operation. This prevents confirmation swapping: evidence for booking flight X cannot be replayed against booking flight Y even if all other fields agree. 2. The requesting session, by challenge. The AA generates the challenge; only a CS that processed this CR signs a CE with this challenge. The AA therefore knows the evidence was produced for its current request, not retrieved from storage. 3. The acting agent, by audience. In delegated flows, evidence names its consumer; other agents cannot use it. 4. The rendering, by rendering-digest, when present. 5. The delegation path, by handoff digests, when present (Section 9.2). Liu Expires 6 May 2027 [Page 18] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 The dependency-closure discipline of [I-D.bu-agentproto-security-principal-binding] applies: a composed verification result is no stronger than its weakest verified input. A CE with an unresolvable key, an unknown method, or an unverifiable digest yields an unverifiable row outcome, not a failure elsewhere to be papered over by an otherwise-valid signature. 7.5. Lifetime and Freshness Evidence is current when verified within "lifetime" seconds of confirmed-at. Verifiers MAY additionally bound the age of the whole chain (CR construction to verification) per local policy. Freshness is anchored at the AA's challenge, not at CS clocks: the AA does not need to trust CS time, only its own clock and its own randomness. CS clock skew affects only the lifetime computation, for which a conservative verifier margin is RECOMMENDED. 8. Verification Procedure 8.1. Verification Steps A verifier (API gateway, enforcement point at AA, or later auditor) processes a presented CE as follows. Steps are ordered; each produces a row outcome (Section 8.2). 1. Presence. If the operation requires confirmation (per Section 10 metadata) and no CE is presented, outcome is "absent". 2. Signature. Validate the JWS against a resolvable CS key. Invalid signature or unresolvable key: outcome "invalid" or "unverifiable" respectively. 3. Action digest. Recompute the digest over the operation being executed, using the operation-to-AD mapping from the action type specification. Compare with CE action-digest. Mismatch: outcome "mismatched". 4. Audience. The CE audience MUST equal the verifier's agent identity (for AA) or the accepting party's identity. Mismatch: "diverted". 5. Decision. decision MUST be "confirmed". "denied": outcome "denied". 6. Freshness. Challenge MUST equal the challenge the verifier issued (if the verifier is the AA); confirmed-at plus lifetime MUST not be in the past; request-id MUST NOT have been seen (Section 8.3). Violations: "stale" or "replay". 7. Policy. auth-context MUST satisfy the verifier's policy for the effect class (Section 7.3). Violation: "insufficient-assurance". Liu Expires 6 May 2027 [Page 19] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 8. Exercise (optional, RECOMMENDED for irreversible actions). If the action type specification defines the required rendering set, recompute the rendering digest and compare with CE rendering- digest. Absent rendering-digest: the verifier cannot establish that the user saw the required fields; outcome "unexercised" if policy requires it. All outcomes other than full success are terminal for the presented CE. The verifier MUST NOT partially accept. 8.2. Outcome Matrix and Error Codes Each row outcome maps to a distinct error signal. This distinct- outcome model is the protocol-level realization of the requirements in [I-D.konda-agentproto-evaluation-state] and CMN-12 of [I-D.agentic-ai-usecases-requirements]: a verifier must be able to determine whether a check failed or could not be completed, and the two cases must produce different signals. Liu Expires 6 May 2027 [Page 20] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 +======================+==========================+================+ |Row outcome |HTTP API error |Retry semantics | +======================+==========================+================+ |absent |confirmation_required |Obtain a | | | |confirmation | +----------------------+--------------------------+----------------+ |invalid |confirmation_invalid |Do not retry | | | |unchanged; alert| +----------------------+--------------------------+----------------+ |unverifiable |confirmation_unavailable |Retry after key | | | |or CS recovery | +----------------------+--------------------------+----------------+ |mismatched |confirmation_mismatch |Regenerate: the | | | |action differs | +----------------------+--------------------------+----------------+ |diverted |confirmation_diverted |Evidence not | | | |issued for this | | | |verifier | +----------------------+--------------------------+----------------+ |denied |confirmation_denied |Only user- | | | |initiated retry | +----------------------+--------------------------+----------------+ |stale |confirmation_stale |Re-request | +----------------------+--------------------------+----------------+ |replay |confirmation_replay |Investigate; do | | | |not auto-retry | +----------------------+--------------------------+----------------+ |insufficient-assurance|confirmation_low_assurance|Re-authenticate | | | |at higher LoA | +----------------------+--------------------------+----------------+ |unexercised |confirmation_unexercised |Re-render with | | | |required fields | +----------------------+--------------------------+----------------+ |success |(accepted) |Execute | +----------------------+--------------------------+----------------+ Table 2 Conflating these outcomes — for example, reporting "denied" for "unobtainable", or "invalid" for "stale" — is a protocol violation. Retry storms, alert misrouting, and audit ambiguity are precisely the costs that motivated the evaluation-state requirements; the error taxonomy exists to prevent them. Liu Expires 6 May 2027 [Page 21] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 8.3. Replay Prevention Replay state is keyed by request-id. The verifying party (AA or API) MUST retain request-ids of accepted CEs for at least the CR lifetime plus a margin. Because request-id is carried inside the signed payload, an attacker cannot mint a fresh id for an old decision without the CS key. Challenge gives AA-side freshness without shared state: for the AA verifier, step 6's challenge check subsumes replay checking for cross-session transplants; request-id state additionally catches same-session replay. 9. Multi-Agent Confirmation 9.1. Delegated Flow In Variant B, the acting agent AA cannot reach the user; the requesting agent RA holds the user dialog. The flow of Section 4.4 applies. Security properties: * RA cannot fabricate evidence (no CS key). * RA cannot alter the action: the AD digest is fixed by AA before RA ever sees the request; alteration is detected by the CS (which renders the AD it received and signs the digest) and by AA at verification. * RA cannot replay evidence: AA's challenge is fresh per request. * RA cannot redirect evidence: audience binding names AA. * RA cannot suppress a denial undetectably: a denial is signed evidence; if RA returns nothing, AA sees "absent", which is distinct from "denied" (Section 9.3). RA can, however, drop the interaction entirely; the denial-signal property holds only for interactions that complete. This residual risk is noted in Section 11. 9.2. Handoff Chain Binding When the task reached AA through a signed handoff chain [I-D.srivastava-agentproto-handoff-context], the CR and CE carry the digest(s) of the handoff offer chain. This binds the confirmation to the delegation path, not merely to the final operation: a CE names the chain of delegated authority under which the action will execute. Verifiers with delegation policy (e.g., "this action may only execute under a delegation chain rooted at enterprise X") check the chain Liu Expires 6 May 2027 [Page 22] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 digest against their policy. The chain itself is carried by the handoff protocol, not by AACP; AACP references it only by digest, keeping this document's formats opaque to the transparency or logging service behind the chain — the same opacity discipline as [I-D.srivastava-agentproto-handoff-context], whose prior context is named by digest only. 9.3. Denied, Unobtainable, and Stale Are Different Facts AACP distinguishes: * denied: the user decided against the action. Signed evidence exists with decision "denied". This is a first-class fact; agents SHOULD record it and MUST NOT silently retry. * unobtainable: the confirmation could not be collected (user unreachable on all channels, CS failure, dialog lifetime expired before collection). Reported by the CS as an unsigned status object: { "request-id": "...", "outcome": "unobtainable", "reason": "channel-unreachable" / "dialog-expired" / "cs-error" / "user-unreachable", "reported-at": "..." } An unsigned status is deliberately weaker than evidence: it is a report, not a decision. It maps to the "confirmation_unavailable" error and to retry-after-recovery semantics. This separation is exactly the konda requirement: collapsing "denied" and "could not be asked" into one value corrupts retry behavior and audit interpretation. * stale: the user confirmed, but the evidence aged out before execution. Maps to "confirmation_stale"; re-request is appropriate. The dialog-interruption semantics of CC3-4 in [I-D.howe-agentproto-contact-center-usecases] (distinguish an interrupted dialog from a terminated one) are preserved here: an interrupted confirmation flow yields "unobtainable" with reason "dialog-expired", not a denial. 10. API Integration APIs declare which operations require confirmation, and how their request fields map to confirmable parameters, through metadata. For OpenAPI-described APIs, this document defines the "x-aacp" extension object: Liu Expires 6 May 2027 [Page 23] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 "x-aacp": { "type": "https://api.airlines.example.com/actions/flight_booking", "actions": ["book"], "confirm-parameters": ["flight_number", "fare_class", "total_price"], "render": { "flight_number": { "label": "Flight" }, "fare_class": { "label": "Cabin", "value-map": { "economy": "Economy", "business": "Business" } }, "total_price": { "label": "Total price", "format": "currency" } } } The extension carries: the action type (URI), the action verbs, the list of request parameters that MUST be confirmed, and rendering metadata per parameter. This is the API annotation machinery required by [I-D.rosenberg-agentproto-usecases] Section 3.2.3: the API owner — the only party able to judge the risk of the operation — decides what requires confirmation and how it is presented. Enforcement: an API whose metadata declares confirmation for an operation MUST reject the operation with "confirmation_required" when no valid CE accompanies it. The API is the last-line verifier; agent-side enforcement alone MUST NOT be relied upon (an agent may be compromised or hallucinating — which is the threat this protocol exists to contain). The API SHOULD also define its operation-to-AD mapping (which request fields become which AD parameters, and their canonical serialization) so that verifiers can recompute the action digest deterministically. For REST APIs, the default mapping is: one AD per API request; parameters map from request body fields by name; locations maps from the endpoint URI. 11. Security Considerations 11.1. Threat Model The protocol defends against: Fabricated confirmation An intermediate or acting agent claims user approval it never obtained. Defeated by the CS signature: fabrication requires the CS key. Residual: CS compromise (Section 11.4). Confirmation swapping Real evidence for action A is applied to action B. Defeated by the action digest; the verifier recomputes over the operation at hand. Replay Old evidence is re-presented. Defeated by challenge (AA-side freshness), request-id tracking, and lifetime. Diversion Evidence issued for one delegation is used for another. Defeated by audience binding. Downgrade / silent skip An agent bypasses confirmation for a Liu Expires 6 May 2027 [Page 24] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 confirmation-required operation. Defeated by API-side enforcement with fail-closed behavior. Rendering attacks Malicious content in AD labels or values attacks the confirmation UI (homoglyphs, crafted formatting, injection into mark-up-capable renderers). Mitigated by the data-not-markup rendering rule (Section 5.2), consistent with the consent- sanitization guidance in [RFC9396]. Renderers MUST escape or reject non-conforming content; homoglyph attacks on labels are mitigated by recommending ASCII labels where practical and by value-label pre-formatting for critical fields. Prompt injection Injected instructions can still cause an agent to CONSTRUCT an undesirable action descriptor; AACP does not prevent this. What AACP guarantees is that the constructed action, whatever it is, is shown to the user for an explicit, non-LLM decision before irreversible execution. This bounds prompt- injection blast radius to actions the user can see and reject. This addresses the containment aspect (not the detection aspect) of the prompt-injection discussion in [I-D.rosenberg-agentproto-usecases] Section 3.3.7. 11.2. Residual Risks RA interaction dropping In Variant B, RA can refuse to relay the CR or the CE. AA sees "absent"/timeout and must not execute. The user is not informed of the dropped interaction by AACP itself; surfacing it is the surrounding dialog protocol's responsibility. CS compromise A compromised CS can sign fabricated confirmations for any action it is asked to confirm. Mitigations: CS keys SHOULD be held in hardware or isolated confirmation UIs; deployment profiles SHOULD scope CS acceptance (verifiers accept only CSes they have policy reasons to trust); the auth-context records the method, so fabricated "passkey" claims require attacking that infrastructure too. CS compromise is a catastrophic failure mode and is not further mitigated by this protocol. User rubber-stamping Confirmation fatigue leads users to approve without reading. A protocol cannot fix this; rendering requirements (explicit controls, no defaults) are the available mitigation. Action type specifications SHOULD minimize the confirmable parameter set to what matters. Time shifting CS clock skew can extend or shorten effective evidence lifetime by the skew amount. Verifier margins are RECOMMENDED. Liu Expires 6 May 2027 [Page 25] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 11.3. Algorithm Agility This document fixes the digest (SHA-256) and requires ES256 or EdDSA signatures. New algorithms enter through a CS key registration update, not through protocol negotiation; signers MUST NOT offer downgrade choices. If SHA-256 requires replacement in the future, the version field "v" governs a revised digest profile; verifiers MUST reject unknown versions. 11.4. Key Management CS keys MUST rotate with overlap exceeding the maximum evidence lifetime (Section 7.2). Verifiers MUST retain retired keys (or a transparency record of them) at least as long as they must verify past evidence — the post-session determinability requirement of [I-D.wadkins-agentproto-action-determinability]. Long-horizon verifiers (auditors) SHOULD anchor key history in an append-only record, e.g., a SCITT-style transparency service [I-D.ietf-scitt-architecture]. 12. Privacy Considerations Confirmation evidence records that a specific user (subject) approved a specific action (descriptor digest) at a time. This is intentionally disclosure-capable information. Considerations: * The CE carries digests, not the descriptor itself. Third parties cannot learn action parameters from a CE without the corresponding AD. Entities that held both (the AA, the CS) already knew the parameters. * Parameters marked render.sensitive=true SHOULD be masked in logs and SHOULD NOT be included in the rendering set stored alongside evidence (the rendering digest commits to them without retaining them). * The auth-context describes method and assurance level, not credentials; it carries no secrets. * Variant C side-channel delivery necessarily reveals the confirmation's existence and its label to the side-channel provider; CR construction SHOULD minimize descriptor content on such channels. * Data minimization: verifiers SHOULD discard evidence after their verification horizon unless retention is required for the action's accountability period; retention policy is deployment-scoped. Liu Expires 6 May 2027 [Page 26] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 13. IANA Considerations 13.1. Media Types This document requests registration of: application/aacp-confirmation-request+json Structure: Section 6; encoding: UTF-8 JSON. application/aacp-confirmation-evidence+json Structure: Section 7; encoding: UTF-8 JSON; a JWS (RFC 7515) compact serialization whose payload is the JCS-canonicalized CE object. application/aacp-confirmation-status+json Structure: Section 9.3; encoding: UTF-8 JSON. A CBOR media type (application/aacp+cbor) is requested for the CBOR profile of Appendix A, content-format TBD. 13.2. Confirmation Outcome Values Registry IANA is asked to create a registry "AACP Row Outcomes" with the values of Section 8.2 (absent, invalid, unverifiable, mismatched, diverted, denied, stale, replay, insufficient-assurance, unexercised, success). New values require Specification Required [RFC8126]. 13.3. Error Code Allocation The HTTP API error codes of Section 8.2 (confirmation_required, confirmation_invalid, ...) are registered in a subregistry with the same policy. Profiles that map outcomes to transport-specific errors MUST preserve their distinctness. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, March 2015, . Liu Expires 6 May 2027 [Page 27] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 8259, December 2017, . [RFC8785] Rundgren, A., Weber, S., and D. Johansson, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Language to Express CBOR and JSON Data Structures", RFC 8610, June 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, May 2015, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, August 2022, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, May 2023, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, May 2024, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, . [FIPS180-4] NIST, "Secure Hash Standard", FIPS PUB 180-4, August 2015. [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017, . 14.2. Informative References Liu Expires 6 May 2027 [Page 28] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 [I-D.rosenberg-agentproto-usecases] Rosenberg, J. and C. Jennings, "Framework, Use Cases and Requirements for AI Agent Protocols", Work in Progress, Internet-Draft, draft-rosenberg-agentproto-usecases-00, 4 July 2026, . Work in Progress. [I-D.bu-agentproto-security-principal-binding] Bu, S., "Security Principal and Verifier Binding for Agent Communication Protocols", Work in Progress, Internet- Draft, draft-bu-agentproto-security-principal-binding-08, 13 October 2026, . Work in Progress. [I-D.he-agentproto-verifier-evidence] He, J. S., "Exercise and Completeness Evidence for Agent Protocol Verifier Results", Work in Progress, Internet- Draft, draft-he-agentproto-verifier-evidence-01, 18 October 2026, . Work in Progress. [I-D.konda-agentproto-evaluation-state] Konda, G., "Preserving Evaluation State in Agent Protocol Decisions", Work in Progress, Internet-Draft, draft-konda- agentproto-evaluation-state-02, 19 October 2026, . Work in Progress. [I-D.wadkins-agentproto-action-determinability] Wadkins, D., "Determinability of Agent Actions", Work in Progress, Internet-Draft, draft-wadkins-agentproto-action- determinability-00, 10 September 2026, . Work in Progress. [I-D.okutomi-session-bound-agent-identity] Okutomi, A., "A Verifier-Side Acceptance Profile for Channel-Bound Agent Identity and Authorization", Work in Progress, Internet-Draft, draft-okutomi-session-bound- agent-identity-06, 30 July 2026, . Work in Progress. [I-D.agentic-ai-usecases-requirements] Reddy, T., Sarker, Z., and K. Yao, "Agentic AI Use Cases and Requirements", Work in Progress, Internet-Draft, Liu Expires 6 May 2027 [Page 29] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 draft-agentic-ai-usecases-requirements-05, 27 October 2026, . Work in Progress. [I-D.srivastava-agentproto-handoff-context] Srivastava, K., "Signed Handoff Context for Agentic Dialogs", Work in Progress, Internet-Draft, draft- srivastava-agentproto-handoff-context-00, 26 October 2026, . Work in Progress. [I-D.feng-agentproto-session-requirements] Feng, C., "Requirements for Agent Session Establishment, Capability Negotiation, and Sessionless Interaction", Work in Progress, Internet-Draft, draft-feng-agentproto- session-requirements-02, 20 August 2026, . Work in Progress. [I-D.howe-agentproto-contact-center-usecases] Howe, T., "Contact Center Use Cases and Requirements for Agentic Dialogs", Work in Progress, Internet-Draft, draft- howe-agentproto-contact-center-usecases-00, 25 October 2026, . Work in Progress. [I-D.ietf-scitt-architecture] Birkholz, H., "An Architecture for Trust Services with Strict Data Integrity", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture, . Work in Progress. [I-D.rosenberg-aiproto-cheq] Rosenberg, J., White, P., and C. Jennings, "Confirmation with Human in the Loop (HITL) Exchange of Quotations (CHEQ)", Work in Progress, Internet-Draft, draft- rosenberg-aiproto-cheq-00, 19 October 2025, . Work in Progress. Expired April 2026. [I-D.liu-agent-operation-authorization] Liu, D., Zhu, J., and S. Krishnan, "Agent Operation Authorization", Work in Progress, Internet-Draft, draft- liu-agent-operation-authorization-02, 15 March 2026, . Work in Progress. Expired September 2026. Liu Expires 6 May 2027 [Page 30] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 [I-D.emerson-oauth-user-mediated-delivery] Emerson, C., "User-Mediated Credential Delivery as a Complementary Authorization Primitive for AI Agents", Work in Progress, Internet-Draft, draft-emerson-oauth-user- mediated-delivery-01, 26 October 2026, . Work in Progress. [CHARTER] IETF, "Agent Communication Protocols (agentproto) Charter", 8 October 2026, . Approved 8 October 2026. [CIBA] OpenID Foundation, "OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0", . [WebAuthn] World Wide Web Consortium, "Web Authentication: An API for accessing Public Key Credentials, Level 2", . W3C Recommendation. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . Appendix A. Complete CDDL Definition The complete CDDL grammar for the three objects, in their CBOR forms (the JSON forms differ only in encoding of binary values and map key types; the JSON form uses base64url without padding and string keys): Liu Expires 6 May 2027 [Page 31] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 start = aacp-confirmation-request / aacp-confirmation-evidence / aacp-confirmation-status aacp-action-descriptor = { type: uri actions: [1* text] ? locations: [1* uri] ? parameters: { * text => aacp-parameter } ? effect: aacp-effect ? reversible: bool ? expires: time * $$aacp-ad-extension } aacp-parameter = { value: any ? confirm: bool ? render: { ? label: text ? value-label: text ? format: text ? sensitive: bool } } aacp-effect = "create" / "update" / "delete" / "transfer" / "communication" aacp-confirmation-request = { v: 1 request-id: uuid-type action-digest: digest challenge: bstr .size 16 lifetime: uint audience: text ? subject: text ? channel: { ? min-loa: uint .le 5 ? modes: [1* text] } ? handoff: [1* digest] * $$aacp-cr-extension } aacp-confirmation-evidence = { v: 1 request-id: uuid-type action-digest: digest challenge: bstr .size 16 decision: "confirmed" / "denied" audience: text ? subject: text confirmed-at: time auth-context: { method: text loa: uint .le 5 ? as: uri } ? rendering-digest: digest ? handoff: [1* digest] * $$aacp-ce-extension } aacp-confirmation-status = { request-id: uuid-type outcome: "unobtainable" reason: "channel-unreachable" / "dialog-expired" / "cs-error" / "user-unreachable" reported-at: time } digest = bstr .size 32 ; SHA-256 uuid-type = bstr .size 16 ; RFC 9562 UUID, binary form ; Extension points use CDDL sockets: $$aacp-ad-extension //= (? aacp-ad-ext: any) $$aacp-cr-extension //= (? aacp-cr-ext: any) $$aacp-ce-extension //= (? aacp-ce-ext: any) Appendix B. Examples B.1. Action Descriptor (flight booking) { "type": "https://api.airlines.example.com/actions/flight_booking", "actions": ["book"], "locations": ["https://api.airlines.example.com/bookings"], "parameters": { "flight_number": { "value": "UA123", "confirm": true, "render": { "label": "Flight", "value-label": "United 123, New York JFK to Los Angeles LAX" } }, "departure_date": { "value": "2026-11-20", "confirm": true, "render": { "label": "Departure", "value-label": "20 November 2026, 09:00 EST" } }, "passenger_name": { "value": "A. Example", "confirm": true, "render": { "label": "Passenger" } }, "fare_class": { "value": "economy", "confirm": true, "render": { "label": "Cabin", "value-label": "Economy" } }, "total_price": { "value": { "currency": "USD", "amount": "412.00" }, "confirm": true, "render": { "label": "Total price", "format": "currency" } }, "seat_preference": { "value": "window" } }, "effect": "create", "reversible": false, "expires": "2026-10-31T12:00:00Z" } Parameters with confirm=true (flight, date, passenger, cabin, price) form the rendering set; seat_preference is part of the action digest but not the confirmation display. Liu Expires 6 May 2027 [Page 32] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 B.2. Confirmation Request { "v": 1, "request-id": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "action-digest": "base64url(SHA-256(JCS(descriptor)))", "challenge": "base64url(16 random octets)", "lifetime": 300, "audience": "agent:booking.airlines.example.com", "subject": "user:alice@example.com" } B.3. Confirmation Evidence (payload before JCS and signing) { "v": 1, "request-id": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "action-digest": "base64url(SHA-256(JCS(descriptor)))", "challenge": "base64url(16 random octets)", "decision": "confirmed", "audience": "agent:booking.airlines.example.com", "subject": "user:alice@example.com", "confirmed-at": "2026-10-31T11:03:17Z", "auth-context": { "method": "passkey", "loa": 4 }, "rendering-digest": "base64url(SHA-256(JCS(rendering-set)))" } B.4. Denied Evidence The same structure with "decision": "denied" and the matching confirmed-at. The acting agent MUST treat denial as a terminal outcome for the request-id and MUST NOT re-request confirmation for the same action-digest without a new user-initiated dialog turn. B.5. Unobtainable Status { "request-id": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "outcome": "unobtainable", "reason": "dialog-expired", "reported-at": "2026-10-31T11:59:02Z" } Appendix C. Requirement Traceability Matrix Each mechanism in this document traces to at least one requirement in the agentproto document set or an external standard: +=======+====================================================+=====+ | ID | Mechanism (section) | Src | +=======+====================================================+=====+ | RR-1 | Programmatic, non-LLM rendering requirement for | 1 | | | the CS (Sec 4.2, 5.2) | | +-------+----------------------------------------------------+-----+ | RR-2 | API annotation of confirmation-required operations | 1 | | | and field-level confirm flags (Sec 5.1, 10) | | +-------+----------------------------------------------------+-----+ | RR-3 | User-visible rendering metadata (render labels, | 1 | Liu Expires 6 May 2027 [Page 33] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 | | value labels, formats) (Sec 5.1, 10) | | +-------+----------------------------------------------------+-----+ | RR-4 | Cryptographic assurance that confirmation | 1 | | | originates from the user, in delegated flows (Sec | | | | 4.4, 7, 9) | | +-------+----------------------------------------------------+-----+ | BU-1 | Action evidence as a separated, digest-bound claim | 2 | | | (Sec 7.1, 7.4) | | +-------+----------------------------------------------------+-----+ | BU-2 | Evidence provenance via CS key identity and auth- | 2 | | | context (Sec 7.2, 7.3) | | +-------+----------------------------------------------------+-----+ | BU-3 | Freshness rules and lifetime bounds (Sec 7.5) | 2 | +-------+----------------------------------------------------+-----+ | BU-4 | Distinct row outcomes with terminal processing, no | 2 | | | partial acceptance (Sec 8) | | +-------+----------------------------------------------------+-----+ | BU-5 | Dependency closure: unresolvable inputs yield | 2 | | | unverifiable, never inflated outcomes (Sec 7.4, | | | | 8.2) | | +-------+----------------------------------------------------+-----+ | HE-1 | Exercise evidence: rendering-digest commits to the | 3 | | | confirmation display the user actually saw (Sec | | | | 5.2, 7.4, 8.1 step 8) | | +-------+----------------------------------------------------+-----+ | HE-2 | Denied decisions produce signed evidence, not | 3,4 | | | silence (Sec 7.1, 9.3) | | +-------+----------------------------------------------------+-----+ | KO-1 | denied / unobtainable / stale as distinct outcomes | 4 | | | with distinct errors (Sec 8.2, 9.3) | | +-------+----------------------------------------------------+-----+ | WA-1 | Post-session verifiability: detached signatures, | 5 | | | key-history retention rules (Sec 7.2, 11.4) | | +-------+----------------------------------------------------+-----+ | WA-2 | Effect classification (effect, reversible) (Sec | 5 | | | 5.1) | | +-------+----------------------------------------------------+-----+ | CM-1 | Verify-at-the-time-authorized and distinguish- | 6 | | | failed-vs-incomplete (CMN-12) (Sec 8.2) | | +-------+----------------------------------------------------+-----+ | SV-1 | Handoff chain binding by digest (Sec 9.2) | 7 | +-------+----------------------------------------------------+-----+ | OK-1 | Audience binding against context diversion (Sec | 8 | | | 7.1, 8.1 step 4) | | +-------+----------------------------------------------------+-----+ | HO-1 | Out-of-band confirmation with dialog-interruption | 9 | | | semantics (Sec 4.4 Variant C, 9.3) | | +-------+----------------------------------------------------+-----+ Liu Expires 6 May 2027 [Page 34] Internet-Draft Agent Action Confirmation Protocol (AACP November 2026 | FE-1 | Channel requirements in the CR, async | 10 | | | reconnection-compatible confirmation (Sec 6) | | +-------+----------------------------------------------------+-----+ | RAR-1 | Descriptor structure derived from | 11 | | | authorization_details (Sec 5.1) | | +-------+----------------------------------------------------+-----+ | RAR-2 | Consent-display sanitization inherited (Sec 5.2, | 11 | | | 11.1) | | +-------+----------------------------------------------------+-----+ Table 3 Sources: 1. [I-D.rosenberg-agentproto-usecases] Sections 3.2.3, 3.3.6 2. [I-D.bu-agentproto-security-principal-binding] claims C-005, C-007, C-008, C-009; row-outcome and closure rules 3. [I-D.he-agentproto-verifier-evidence] 4. [I-D.konda-agentproto-evaluation-state] 5. [I-D.wadkins-agentproto-action-determinability] 6. [I-D.agentic-ai-usecases-requirements] CMN-12 7. [I-D.srivastava-agentproto-handoff-context] 8. [I-D.okutomi-session-bound-agent-identity] 9. [I-D.howe-agentproto-contact-center-usecases] CC3-1, CC3-4 10. [I-D.feng-agentproto-session-requirements] 11. [RFC9396] Appendix D. Acknowledgments The requirement structure of this document is drawn from the agentproto working group's document set; the author acknowledges the authors of those documents for the analysis this protocol builds on. The action descriptor design reuses the Rich Authorization Requests structure of RFC 9396, whose authors' deployment experience informed several profile decisions. Author's Address Meihui Liu China Mobile Email: liumeihui@chinamobile.com Liu Expires 6 May 2027 [Page 35]