Network Working Group D. Liu Internet-Draft Alibaba Intended status: Standards Track 2 November 2026 Expires: 6 May 2027 Scenario-Based Service Discovery and Authorization Protocol in Agent Environments draft-liu-oauth-scenario-discovery-authz-00 Abstract AI agents act on behalf of end users across applications the agent has no prior relationship with and cannot pre-register with. This specification defines a scenario-based service discovery and authorization protocol for agent environments, which lets an application advertise its capabilities to agents, lets an agent learn how to invoke the application, with which authorization mechanism, and how to obtain a delegated session for the end user without ever handling the end user's primary credentials, and lets the application enforce runtime interaction boundaries when an agent operation exceeds what was approved. The protocol combines two building blocks. The first is a semantic standard for an application's scenario-based capability advertisement: the scenaric flows the application opens to agents, the operations each flow packages, and the authorization mechanisms and invocation surfaces it accepts for them; what no flow opens is closed by default. The second is an attach and binding standard that attaches the semantic to both mobile applications and web applications, so one advertisement reaches an agent over a web origin or through a packaged native application. The protocol reuses OAuth standards that exist or are being defined and defines no new authorization protocol: the advertisement is a standalone document at its own well-known location, linked from Protected Resource Metadata; the delegated session is established by the grants the advertisement names; tokens are sender-constrained with DPoP; runtime boundaries are carried by Rich Authorization Requests and verified by the authorization schemas framework, whose reverse-guided refusals route the agent back to re-establishment. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Liu Expires 6 May 2027 [Page 1] Internet-Draft Scenario Discovery and Authorization November 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 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 2. Terminology and Architecture Overview . . . . . . . . . . . . 5 3. The Scenario Advertisement Semantic . . . . . . . . . . . . . 6 3.1. The Capability Document . . . . . . . . . . . . . . . . . 7 3.2. Intent Matching . . . . . . . . . . . . . . . . . . . . . 14 3.3. The 401 Challenge: Runtime Error Correction . . . . . . . 14 4. Attaching the Advertisement to Web and Native Applications . 16 4.1. Web Applications . . . . . . . . . . . . . . . . . . . . 16 4.2. Native Applications . . . . . . . . . . . . . . . . . . . 17 4.3. Relationship to Existing Discovery Mechanisms . . . . . . 18 5. Authorization Establishment Modes . . . . . . . . . . . . . . 19 5.1. The ID-JAG . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Authorization Server Processing Requirements . . . . . . 21 5.3. Mode A: Front-Channel Establishment with Schema Annotation . . . . . . . . . . . . . . . . . . . . . . . 22 5.4. Mode B: Back-Channel Establishment under ID-JAG . . . . . 24 5.4.1. Mode B1: Host-Mediated Assertion . . . . . . . . . . 24 5.4.2. Mode B2: Pending Approval . . . . . . . . . . . . . . 25 5.4.3. Mode B3: Silent Establishment . . . . . . . . . . . . 26 5.5. One Session, All Surfaces, One Primary Path . . . . . . . 27 Liu Expires 6 May 2027 [Page 2] Internet-Draft Scenario Discovery and Authorization November 2026 6. Agent Identity and Token Binding . . . . . . . . . . . . . . 28 6.1. Agent Client Authentication . . . . . . . . . . . . . . . 28 6.2. DPoP Binding . . . . . . . . . . . . . . . . . . . . . . 28 7. Runtime Enforcement and Remediation . . . . . . . . . . . . . 28 7.1. Atomic Constraint Verification . . . . . . . . . . . . . 29 7.2. Remediation Through Re-Establishment . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8.1. Credential Isolation . . . . . . . . . . . . . . . . . . 31 8.2. Establishment Mode Equivalence . . . . . . . . . . . . . 31 8.3. Remediation Guidance Authenticity . . . . . . . . . . . . 33 8.4. Confirmation Fatigue . . . . . . . . . . . . . . . . . . 33 8.5. Token Lifetime and Revocation . . . . . . . . . . . . . . 33 8.6. Advertisement Integrity . . . . . . . . . . . . . . . . . 34 8.7. Native Surface Launch . . . . . . . . . . . . . . . . . . 34 8.8. Privacy Considerations . . . . . . . . . . . . . . . . . 35 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 9.1. Well-Known URI Registration . . . . . . . . . . . . . . . 35 9.2. OAuth Protected Resource Metadata Registration . . . . . 36 9.3. Agent Capability Document Fields Registry . . . . . . . . 36 9.4. Agent Establishment Mode Identifiers . . . . . . . . . . 37 9.5. Agent Surface Types Registry . . . . . . . . . . . . . . 39 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 10.1. Normative References . . . . . . . . . . . . . . . . . . 39 10.2. Informative References . . . . . . . . . . . . . . . . . 41 Appendix A. Complete End-to-End Use Case: Booking a Flight . . . 42 A.1. Discovery and Matching . . . . . . . . . . . . . . . . . 42 A.2. Session Establishment . . . . . . . . . . . . . . . . . . 43 A.3. Within Bounds . . . . . . . . . . . . . . . . . . . . . . 43 A.4. The Refusal . . . . . . . . . . . . . . . . . . . . . . . 43 A.5. The Retry . . . . . . . . . . . . . . . . . . . . . . . . 44 A.6. The Audit Trail . . . . . . . . . . . . . . . . . . . . . 45 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 45 Stale Packaged Advertisements . . . . . . . . . . . . . . . . . 45 Silent Establishment Consent Records . . . . . . . . . . . . . 45 Mode A Annotation Scope . . . . . . . . . . . . . . . . . . . . 46 Mode B2 Approval Solicitation . . . . . . . . . . . . . . . . . 46 Web Session Exchange . . . . . . . . . . . . . . . . . . . . . 46 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 46 1. Introduction A personal agent that receives an instruction such as "book the cheapest flight to Shanghai tomorrow" must find an application that can fulfill it, act for the user inside that application, and stop or escalate when an operation falls outside what the user approved. Applications today present themselves to agents through structured interfaces, an HTTP API or increasingly a Model Context Protocol Liu Expires 6 May 2027 [Page 3] Internet-Draft Scenario Discovery and Authorization November 2026 (MCP) [MCP] server, and through graphical interfaces built for human eyes: a web site and a native mobile application. The OAuth machinery for every piece of that path already exists; what an agent lacks is the application's own statement of how the pieces apply to it. This specification defines the scenario-based service discovery and authorization protocol for agent environments, which lets an application advertise its capabilities to agents; it lets an agent learn how to invoke the application, with which authorization mechanism, and how to obtain a delegated session for the end user without ever handling the end user's primary credentials; and it lets the application enforce runtime interaction boundaries when an agent operation exceeds what was approved. The protocol combines two building blocks: 1. A semantic standard for the application's scenario-based capability advertisement, which lets an agent discover what functions the application has opened for agent invocation, which authorization standards govern them, and which invocation mechanisms the application accepts for them (Section 3). 2. An attach and binding standard that attaches the semantic to both mobile applications and web applications, so the same advertisement reaches an agent over a web origin, through a packaged native application, or over a platform channel (Section 4). Both building blocks reuse OAuth standards that exist or are being defined; this specification defines no new authorization protocol. The advertisement is a standalone JSON document published at the well-known agent-capabilities location of the application's origin, which Protected Resource Metadata [RFC9728] links to with a single new parameter; the delegated session is established by the grants the advertisement names, the authorization code grant with Pushed Authorization Requests [RFC9126] and the Identity Assertion JWT Authorization Grant (ID-JAG) [I-D.ietf-oauth-identity-assertion-authz-grant], with pending delivery under [I-D.ietf-oauth-deferred-token-response]; the issued tokens are sender-constrained with DPoP [RFC9449] and carry their boundaries in authorization_details [RFC9396]; and runtime verification and remediation run on the authorization schemas framework [I-D.liu-oauth-authorization-schemas]. What the two building blocks add is the scenario semantic, its attachment to web and native applications, and the composition that makes the reused standards work together. Liu Expires 6 May 2027 [Page 4] Internet-Draft Scenario Discovery and Authorization November 2026 The full lifecycle of a protocol interaction therefore runs in four phases: capability discovery, intent matching, establishment mode selection and session establishment, and runtime enforcement with atomic constraints and remediation. The protocol is applicable to human-driven clients as well, but its requirements are shaped by agents: their actions are planned at runtime, their remediation must be machine-readable, and their identity must be demonstrated, not assumed. 2. Terminology and Architecture Overview This specification uses the terms "authorization server" (AS), "client", "resource server" (RS), and "access token" defined in [RFC6749], the authorization_details structure defined in [RFC9396], and the DPoP binding defined in [RFC9449]. Where the capability document reuses the resource and authorization_servers field names of the Protected Resource Metadata [RFC9728], it does so with the same semantics. 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. In addition, this specification defines the following roles and objects: Agent: An autonomous OAuth client that pursues delegated work on behalf of an end user, planning its operation sequence at runtime. In this specification, "client" and "agent" are used interchangeably. Application (Service Provider): The party operating a protected resource. An application exposes its capabilities through structured surfaces, an HTTP API or a Model Context Protocol (MCP) [MCP] server, and through presentation surfaces, a web site and a native mobile application. All surfaces are backed by the same resource servers and authorization server. Host Container: The environment the agent runs in, such as a phone operating system or a browser engine, which mediates user-facing interaction and credential handling on the agent's behalf. The host container renders confirmation surfaces and transmits session credentials into web and native application surfaces; the agent itself never handles the end user's primary credentials. Establishment Mode: The authorization protocol by which an agent Liu Expires 6 May 2027 [Page 5] Internet-Draft Scenario Discovery and Authorization November 2026 obtains delegated authorization for an end user, one of the modes defined in Section 5 and advertised in establishment_modes_supported. The Mode B profiles issue an ID- JAG; Mode A issues an access token of the authorization code grant. Modes differ in where and when the end user interacts, not in the claims of the token issued (Section 5.1). Authorization Schema: A domain-specific authorization schema as defined in [I-D.liu-oauth-authorization-schemas]: a structured definition of behavioral boundaries, instantiated in authorization_details and verified by the resource server through deterministic constraint evaluation. Atomic Capability: A single operation the application exposes, expressible as an operation identifier within a schema instance, such as ecommerce.purchase. Scenaric Flow: A composite, higher-level intent the application packages from atomic capabilities, such as "compare and buy", advertised with the operations it opens and the establishment modes and invocation surfaces it accepts. Capability Document: The JSON document an application publishes at the well-known agent-capabilities location of its origin, packaging the service description, the invocation and presentation surfaces, the scenaric flows, and the authorization pointers that together constitute its capability advertisement. The architecture keeps the division of labor of the underlying specifications intact: the AS is the only issuer of authorization, the RS is the policy enforcement point, and the agent is the execution subject whose every operation is verified. This protocol adds the advertisement semantic and its attachment methods, and composes the session establishment and remediation machinery from the underlying specifications; it does not move authorization decisions into the agent or the host container. 3. The Scenario Advertisement Semantic This chapter defines the first building block: the semantic standard for the application's scenario-based capability advertisement. Discovery is the protocol's front door. An application publishes one capability document at the well-known agent-capabilities location of its origin, and an agent that reads it knows, before it holds any authorization: the service it has reached, the scenaric flows the application opens, the operations each flow packages, and the establishment modes and invocation surfaces each flow accepts. What no flow opens is closed by default. Liu Expires 6 May 2027 [Page 6] Internet-Draft Scenario Discovery and Authorization November 2026 3.1. The Capability Document This section defines the semantics of the capability advertisement: what an application declares and how the declaration is interpreted. How the advertisement reaches an agent, fetched from the well-known HTTPS location, packaged into a native application, or delivered over any future channel, is defined separately in Section 4. The two are deliberately independent: the semantics of what is declared do not depend on the channel it arrived through, and new attachment methods can be defined without changing this section. An application implementing this protocol publishes a capability document: a standalone JSON document served at the well-known agent- capabilities location of its origin (Section 4.1). The document is self-sufficient: it carries its own origin binding, the authorization pointers an agent needs, and the scenario advertisement, so an agent that has fetched it holds everything required to select and establish a session. Protected Resource Metadata [RFC9728] is not extended by this specification; when an application publishes it, it links to the capability document with the single agent_capabilities_uri parameter defined in Section 4.1. The fields are illustrated by the capability document of a shopping application, in the document's reading order: the service description, the origin and surfaces, the scenaric flows, and the authorization pointers: { "service": { "name": "Example Shop", "description": "E-commerce.", "logo_uri": "https://shop.example/logo.png", "policy_uri": "https://shop.example/privacy", "tos_uri": "https://shop.example/tos" }, "resource": "https://shop.example", "invocation_surfaces_supported": [ { "type": "mcp", "url": "https://mcp.shop.example/mcp", "description": "Product search and cart tools.", "token": { "type": "bearer", "sender_constraint": "dpop" } }, { "type": "http_api", "url": "https://api.shop.example", "description": "Orders, cart, and payment operations.", "token": { "type": "bearer", "sender_constraint": "dpop" } }, { Liu Expires 6 May 2027 [Page 7] Internet-Draft Scenario Discovery and Authorization November 2026 "type": "web", "browser_session_endpoint": "https://shop.example/agent/sso" }, { "type": "native_app", "associated_origin": "https://shop.example", "platforms": [ { "platform": "android", "package": "com.example.shop", "app_link": "shopapp://agent/handoff" }, { "platform": "ios", "app_link": "shopapp://agent/handoff" } ] } ], "scenaric_flows_supported": [ { "flow_id": "compare-and-buy", "name": "Compare and buy", "description": "Search, compare prices, and buy.", "schemas": ["transaction_authority"], "operations": ["ecommerce.search", "ecommerce.compare", "ecommerce.cart.add", "ecommerce.purchase"], "access": ["mcp", "http_api"], "entry_points": ["/search", "/products"] }, { "flow_id": "loyalty-balance", "name": "Loyalty balance", "description": "Read loyalty points and membership status.", "schemas": ["loyalty_account"], "operations": ["loyalty.read"], "access": ["http_api"] }, { "flow_id": "gift-card-send", "name": "Send a gift card", "description": "Buy and send a gift card to an email address.", "schemas": ["transaction_authority"], "operations": ["ecommerce.giftcard.purchase", "ecommerce.giftcard.send"], "establishment_modes": ["par", "id-jag", "id-jag-pending"], "access": ["http_api"] } Liu Expires 6 May 2027 [Page 8] Internet-Draft Scenario Discovery and Authorization November 2026 ], "authorization_servers": ["https://as.shop.example"], "establishment_modes_supported": [ "par", "id-jag", "id-jag-pending", "id-jag-silent" ], "authorization_schemas_supported": [ { "type": "transaction_authority", "description": "E-commerce transaction boundaries.", "schema_uri": "https://shop.example/schemas/transaction_v2" }, { "type": "loyalty_account", "description": "Loyalty points and membership boundaries.", "schema_uri": "https://shop.example/schemas/loyalty_v1" } ] } Figure 1: Capability document example The fields are defined as follows, in the document's reading order: the service description, the origin and surfaces, the scenaric flows, and the authorization pointers. service: REQUIRED. An object of display data describing the application itself, for agent-side user interfaces, consent surfaces, and audit records. Its members are not identity claims: the trust anchors of the document are resource and the channel it arrived through (Section 8.6). It contains name (REQUIRED; a human-readable display name of the service: an agent that presents an interaction to the end user identifies the application by this name, together with the origin of resource), description (OPTIONAL; a short human-readable description of the service), and logo_uri, policy_uri, and tos_uri (all OPTIONAL; URIs of a displayable logo, the privacy policy, and the terms of service). Display members MAY carry language tag suffixes, such as name#zh- CN, so that one service can present itself in several languages. resource: REQUIRED. The HTTPS origin of the application, with the same name and semantics as the resource metadata parameter of [RFC9728]. It is the document's self-binding anchor: a capability document fetched from a web origin is authentic for exactly that origin, and a packaged copy is bound to the resource it carries through the verification of Section 4.2. invocation_surfaces_supported: REQUIRED. An array of objects, one Liu Expires 6 May 2027 [Page 9] Internet-Draft Scenario Discovery and Authorization November 2026 per surface through which an agent can act on this application. It is the surface catalog: the URL and the token carriage of each surface are declared once here, and every scenaric flow's access refers to entries of this array by their type. The type of each entry MUST be unique within the array. Each object contains: type: REQUIRED. The surface type. This specification defines http_api, mcp, web, and native_app; further types are registered in the "Agent Surface Types" registry (Section 9.5). url: REQUIRED for the http_api and mcp types. The base URL of the HTTP API or of the MCP [MCP] server. token: REQUIRED for the http_api and mcp types. An object describing how the agent presents its token on the surface. It contains type (REQUIRED; the presentation mechanism; this specification defines bearer, the Authorization header of [RFC6750]) and sender_constraint (OPTIONAL; the sender- constraining mechanism; this specification defines dpop, [RFC9449]). Applications conforming to this specification SHOULD require dpop. description: OPTIONAL. A short human-readable description of the work possible through this surface, intended for agent-side planning and, where applicable, for presentation to the end user. browser_session_endpoint: REQUIRED for the web type. The endpoint at which the host container establishes a web session by exchanging the agent's token (Section 5.5). associated_origin: REQUIRED for the native_app type. The HTTPS origin whose well-known advertisement the packaged copy mirrors (Section 4.2). platforms: OPTIONAL for the native_app type. An array of objects, one per mobile platform for which a packaged application exists. Each object contains: platform: REQUIRED. The platform identifier, such as android or ios. app_link: REQUIRED. A URI that opens the application on that platform, typically the application's registered custom scheme URI. It is the deep-link entry to the native surface: a host container on a platform without app-to-app explicit launch opens it directly. Liu Expires 6 May 2027 [Page 10] Internet-Draft Scenario Discovery and Authorization November 2026 package: OPTIONAL. The platform application identifier, such as an Android package name. A host container on Android SHOULD launch the application with an explicit intent targeting this package: explicit launch reaches the target application directly, without URI-based resolution, so another application that registered the same custom scheme cannot intercept the launch. The app_link remains the deep- link entry once the application is running. scenaric_flows_supported: OPTIONAL. An array of objects, one per composite flow the application opens to agents. Each object contains: flow_id: REQUIRED. A stable identifier of the flow, unique within this metadata document. name: REQUIRED. A short human-readable name. description: OPTIONAL. A human-readable description of what the flow accomplishes, expressed in terms the end user can understand. schemas: REQUIRED. An array of the schema types whose atomic capabilities the flow composes. Every type listed here SHOULD also appear in authorization_schemas_supported. operations: REQUIRED. An array of the atomic capabilities the flow opens. Each operation identifier belongs to the value space of the schema types the flow composes. establishment_modes: OPTIONAL. An array of establishment mode identifiers naming the modes a session covering this flow's operations may use. Each identifier MUST also appear in establishment_modes_supported; when the member is absent, every advertised mode is accepted. A flow MAY narrow the list to modes whose end user interaction is synchronous: the gift-card- send flow of Figure 1 excludes silent establishment, so a session that moves value to a third party is always established with user interaction, even when it renews. access: REQUIRED. An array of surface type names, one per structured surface through which the flow's operations are reachable. Each name MUST match the type of an entry in invocation_surfaces_supported; the URL and the token carriage of that entry apply to every operation of this flow invoked on that surface. A flow MAY accept a subset of the application's structured surfaces. Liu Expires 6 May 2027 [Page 11] Internet-Draft Scenario Discovery and Authorization November 2026 entry_points: OPTIONAL. An array of resource paths or URIs at which the flow typically starts, for agents that navigate resource structures directly. Flows are the unit of exposure. An atomic capability is open to agents exactly when it appears in the operations of at least one advertised flow; an operation no advertised flow opens is closed by default, whatever an approved instance says. The resource server MUST NOT execute a closed operation, and the authorization server SHOULD decline an instance whose boundary includes one. An application willing to accept a capability outside any packaged flow MUST open it, by advertising a flow that lists it. authorization_servers: REQUIRED. An array of authorization server issuer URLs, with the same name and semantics as the authorization_servers metadata parameter of [RFC9728]: the agent fetches each issuer's AS metadata document [RFC8414] to obtain the token endpoint and the remaining endpoints. The capability document carries the pointer itself, so an agent that has fetched the document can begin establishment without any other metadata document of the application. When the application also publishes Protected Resource Metadata, its authorization_servers value MUST be identical to this one. establishment_modes_supported: OPTIONAL. An array of establishment mode identifiers, one per authorization establishment mode (Section 5) the application's authorization servers accept for this resource: par (Mode A), id-jag (Mode B1), id-jag-pending (Mode B2), or id-jag-silent (Mode B3), registered in the "Agent Establishment Mode Identifiers" registry (Section 9.4). These are identifiers of this specification, not OAuth parameters. A grant type alone often does not determine the authorization protocol an agent is expected to run: the three ID-JAG modes share one grant type, and the mode identifier distinguishes them. Liu Expires 6 May 2027 [Page 12] Internet-Draft Scenario Discovery and Authorization November 2026 Applications conforming to this specification MUST advertise and support Mode A, the interoperability baseline, and SHOULD additionally advertise an ID-JAG profile for agent-native deployments. An agent implements one or more modes and selects an advertised entry it implements; agents deployed outside the end user's device cannot run Mode B1 (Section 5.4.1). If the authorization server rejects the selected entry, it responds with the error of the underlying grant specification, and the agent reselects from the advertisement. The authorization server endpoints are not duplicated in the advertisement: the agent obtains the token endpoint and the remaining AS endpoints from the AS metadata document [RFC8414], discovered from an issuer URL listed in authorization_servers. An application MUST NOT advertise a grant type that none of its listed authorization servers supports, and MUST NOT advertise a mode that none of them implements. authorization_schemas_supported: OPTIONAL. An array of objects, one per authorization schema the resource servers of this application accept in authorization_details. Each object contains: type: REQUIRED. The authorization details type identifier of the schema, as defined in [I-D.liu-oauth-authorization-schemas]. Type identity is exact string match. description: OPTIONAL. A short human-readable description of the capability area the schema governs, intended for agent-side planning and, where applicable, for presentation to the end user. schema_uri: OPTIONAL. A URI dereferencing to a JSON Schema document describing the structure of conforming instances. The dereferenced document is a descriptive input for instance construction, not an authorization. The http_api and mcp entries declare the structured surfaces, the primary path of Section 5.5; the web and native_app entries declare the presentation surfaces. An application has exactly one capability document. Whatever channel an agent obtains it through, the declaration MUST carry the same semantics; how channel-specific copies are kept consistent with the document is defined by the attachment methods in Section 4. Liu Expires 6 May 2027 [Page 13] Internet-Draft Scenario Discovery and Authorization November 2026 3.2. Intent Matching When an agent receives an end user instruction, it matches the instruction against the advertised capabilities: a vague intent such as "buy the cheapest flight to Shanghai tomorrow" maps to a scenaric flow (compare-and-buy) when the application advertises one, or is composed from the operations of several flows otherwise. The advertisement is an input to the agent's planning: the agent composes its session request from the flows the application opened, within the boundary the end user approves at establishment. This specification deliberately defines only the data format of the advertisement, not the matching algorithm. Matching quality is an agent-side competitive property; interoperability requires only that every application describe itself in the same shape. One property of the advertisement is worth stating explicitly, because agents reach applications through more than one structured surface. An atomic capability opened by a flow is the same capability whether the agent invokes it as a direct HTTP API operation or as a tool of an MCP [MCP] server the flow's access declares: it is authorized by the same schema instance and verified by the same resource server. Applications that expose an MCP server SHOULD map each advertised atomic capability to an MCP tool, invoked with the agent's token and a DPoP proof like any API call. 3.3. The 401 Challenge: Runtime Error Correction An authorization challenge is a runtime signal, not an entry point into discovery. When an agent calls an application without a sufficient session, the resource server responds with the reverse- guided authorization challenge of Section 5 of [I-D.liu-oauth-authorization-schemas], which this specification uses as defined there: the insufficient_authorization error code with the schema_profile_uri parameter when the deficiency is structural, insufficient_scope [RFC6750] when it is scope-based. The response also carries the resource_metadata parameter of [RFC9728]: Liu Expires 6 May 2027 [Page 14] Internet-Draft Scenario Discovery and Authorization November 2026 HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer error="insufficient_authorization", schema_profile_uri="https://shop.example/profiles/compare-and-buy", resource_metadata= "https://shop.example/.well-known/oauth-protected-resource" Content-Type: application/json { "error": "insufficient_authorization", "error_description": "A delegated session is required." } Figure 2: Reverse-guided 401 challenge The resource_metadata URI addresses the application's Protected Resource Metadata document, which links to the capability document with the agent_capabilities_uri parameter (Section 4.1). The agent follows the chain, fetches the capability document, selects the scenaric flow or atomic capabilities matching its intent, and constructs the schema instance it will request, following the adaptive behavior defined in [I-D.liu-oauth-authorization-schemas]. Because the well-known location of the capability document is itself guessable, an agent that knows which origin it addressed MAY instead retry discovery directly at that origin's agent-capabilities location; the challenge path additionally covers the case where the origin addressed is not the application's canonical resource. The challenge is error correction, and the reverse path is a fallback rather than the primary one. An agent that obtained the capability document through one of the forward channels of Section 4 (a well- known fetch, a packaged copy in the application, or a platform channel) matches its intent against the document and proceeds to establishment mode selection (Section 5) without any call being refused first. The reverse entry point serves the agent that arrives at a resource endpoint holding nothing but a URL, a deep link, an address handed over by another agent, or one found in content, or an agent whose held advertisement is stale; such an agent learns where the capability document lives from the refusal itself. The same challenge structure carries the remediation signpost when an operation later exceeds the approved authorization (Section 7.2). Nothing in this step is specific to this protocol beyond the document the chain leads to. Liu Expires 6 May 2027 [Page 15] Internet-Draft Scenario Discovery and Authorization November 2026 4. Attaching the Advertisement to Web and Native Applications This section defines the second building block: the attach and binding standard that attaches the advertisement semantic to both mobile applications and web applications. The attachment methods defined here are transport for the same semantics: an agent that discovers the application over a web origin, through a packaged native application, or over any future channel defined elsewhere, interprets one advertisement and runs one protocol. An agent that already holds the advertisement, fetched from the well-known location, read from a packaged copy, or delivered by a platform channel, proceeds directly to intent matching (Section 3.2) and establishment mode selection (Section 5); the 401 challenge of Section 3.3 is the error-correction fallback for an agent that arrives holding nothing but a resource URL. The binding of an established session to the web and native presentation surfaces is defined in Section 5.5. Additional attachment methods MAY be defined in future specifications; they need only deliver the advertisement and the session credentials in accordance with the isolation requirements of Section 8.1, and change nothing in Section 3, Section 5, or Section 7. 4.1. Web Applications For an application that operates a web origin, the capability document is published at the well-known location agent-capabilities under that HTTPS origin: GET /.well-known/agent-capabilities Host: shop.example The location is guessable in the manner of the AS metadata well-known of [RFC8414]: an agent that knows the origin fetches the capability document without any prior registration, and the document returned over authenticated TLS under that origin is authentic for it. The document is served as application/json. All protocol interactions over the structured surfaces run over standard HTTPS. Use of the web presentation surface follows Section 5.5: the host container mediates the web credential; the agent never holds it. Liu Expires 6 May 2027 [Page 16] Internet-Draft Scenario Discovery and Authorization November 2026 The document's scope is the origin that serves it, restated in the document's own resource member (Section 3.1); an agent that finds the two in disagreement holds no advertisement for that origin (Section 8.6). Because any agent may fetch the location without prior arrangement, the endpoint SHOULD be served as static content under a cache lifetime the application controls, which keeps discovery traffic off the application's request path. An application implementing this specification also publishes its Protected Resource Metadata [RFC9728] with one additional parameter: agent_capabilities_uri: REQUIRED. The HTTPS URL of the application's capability document. This is the only linkage between the two documents: the capability document is standalone and self-sufficient, and the Protected Resource Metadata adds nothing but the pointer. The link is what makes the error- correction chain of Section 3.3 work, an agent that skipped discovery follows it from the refused call to the Protected Resource Metadata and on to the capability document, and it serves OAuth clients that begin from the Protected Resource Metadata. When both documents are published, their authorization_servers values MUST be identical (Section 3.1). 4.2. Native Applications For an application that also ships a native mobile application, the capability document is additionally packaged into the application: the application declares, through the operating system's associated- domain mechanisms, the same origin that serves the well-known capability document, and ships a copy of the document in its application package. The declared origin is the associated_origin of the native_app surface entry when the document includes one. The operating system verifies the association between the application and the declared origin through the platform's link-verification chain, for example Android App Links [APPLINKS] and Universal Links [UNIVLINKS]. A host-side agent that wants to act on the packaged application reads the packaged document over the local inter-process channel, without any network access: the packaged copy is what makes offline capability discovery possible. The application MUST treat the packaged copy as a cache of the origin-served document: before the first remote operation of a session, the application checks the origin-served document and MUST use the origin-served copy whenever the two differ. A flow the stale packaged copy still lists is open only until the first refresh, and the application MUST NOT execute an operation that the current origin-served document no longer opens. Liu Expires 6 May 2027 [Page 17] Internet-Draft Scenario Discovery and Authorization November 2026 A host container that opens the native application uses the platforms entries of the native_app surface. On Android, it SHOULD launch the application with an explicit intent targeting the declared package, which reaches the target application directly without URI-based resolution, so another application that registered the same custom scheme cannot intercept the launch; the declared app_link is the deep-link entry, on Android once the application is running, and on platforms without app-to-app explicit launch, such as iOS, where the host container opens the app_link URI directly. These addresses are pointers to existing platform behavior, custom scheme registration and verified app links; this specification defines no launch mechanism of its own. Because custom scheme registration carries no verification, the session credentials of the native surface are never carried in the link URI itself: they travel over the host platform's secure channel, and where a handoff must travel through a URL, it carries a short-lived, single-use reference redeemable at the application, not the token (Section 8.7). Native-surface session establishment runs over the same local inter- process channel, using the host platform's secure credential passing; the channel requirements of Section 5.5 apply. 4.3. Relationship to Existing Discovery Mechanisms An origin may serve several discovery artifacts at once. AS metadata [RFC8414] and Protected Resource Metadata [RFC9728] answer where the authorization servers and the resource endpoints are. Both are protocol metadata for OAuth participants, and neither carries a description of what the application opens to agents; the capability document points at the first and is pointed at by the second, through agent_capabilities_uri (Section 4.1). API catalogs [RFC9727] enumerate the APIs an origin exposes, each entry linking to a description of that API. An application that serves both MAY link from a catalog entry to its capability document, and an agent MAY follow the link, but this specification does not require a catalog, and a catalog with no such link says nothing about whether the application opens flows to agents. Agent Cards [A2A], at the registered agent-card.json well-known, describe an agent: its identity, its skills, the authentication it requires. The capability document describes the application that agent is calling: which flows it opens, under which grants, over which surfaces. One origin MAY serve both, and an agent described by a card of its own still reads the capability document of every application it calls. Liu Expires 6 May 2027 [Page 18] Internet-Draft Scenario Discovery and Authorization November 2026 A key directory for HTTP message signatures [I-D.ietf-webbotauth-httpsig-protocol], at the http-message- signatures-directory well-known that specification requests, identifies the agent as the caller: the agent signs the request with [RFC9421], names in Signature-Agent the URL where it publishes its keys, and the receiving origin resolves that URL and verifies the signature. The directory is served by the agent's own origin, and the URL, not the key, is the identifier, so an agent rotates keys without changing who it is. That specification defines neither authorization nor delegation, and leaves to origin policy whether a request is authorized: a verified signature says which agent asked, not what the end user approved. An agent MAY sign its fetch of the capability document and an application MAY treat signed and unsigned fetches differently, and this specification requires neither. 5. Authorization Establishment Modes The semantic names which authorization standards to run; this chapter defines how an agent runs them. The capability advertisement names, in establishment_modes_supported, the authorization establishment modes the application's authorization servers accept. A mode is a profile of an existing OAuth grant, not a new authorization protocol: Mode A is the authorization code grant with Pushed Authorization Requests [RFC9126], and the Mode B family runs the Identity Assertion JWT Authorization Grant (ID-JAG) [I-D.ietf-oauth-identity-assertion-authz-grant]. The modes differ in where and when the end user interacts and in what the agent authenticates with, but not in what comes out: the Mode B profiles issue the ID-JAG of Section 5.1, and Mode A issues an access token of the authorization code grant, carrying the same claims. This chapter defines the common outcome first, the authorization server processing shared by every mode (Section 5.2), then the modes in two families. Mode A (Section 5.3) is the front-channel mode, a profile of the authorization code grant with Pushed Authorization Requests, in which the end user reviews and may annotate the proposed schema instance on the authorization server's consent surface. Mode B (Section 5.4) is the back-channel family under the Identity Assertion JWT Authorization Grant (ID-JAG) [I-D.ietf-oauth-identity-assertion-authz-grant], in three interaction profiles: host-mediated interaction before the token request, pending approval after it, and silent establishment with no fresh interaction. Mode A is the interoperability baseline: an application conforming to this specification MUST support it, because it runs on machinery every conventional authorization server already offers. The Mode B profiles suit agent-native deployments, where the host container can Liu Expires 6 May 2027 [Page 19] Internet-Draft Scenario Discovery and Authorization November 2026 mediate user interaction without a browser round trip. An agent selects one advertised entry that it implements: agents running inside a host container can run any mode, while agents deployed outside the end user's device, such as cloud agents, cannot produce host-mediated assertions and therefore run Mode A or Mode B2. No negotiation protocol is defined, and none is needed: the advertisement is the complete list, and a wrong selection is corrected by the error of the underlying grant specification. 5.1. The ID-JAG The token of the Mode B profiles is the ID-JAG: the agent requests it with requested_token_type set to urn:ietf:params:oauth:token-type:id- jag, and the AS returns it in the access_token parameter with token_type set to N_A, as in the token exchange response of [RFC8693]. Mode A instead issues the access token of the authorization code grant of [RFC6749]. Both are JWTs whose sub claim is the end user, whose aud and client identity identify the application and the agent respectively, whose authorization_details carry the approved schema instance, and whose lifetime is short. For a session with the application of Figure 1 whose approved boundary limits purchases to 200 USD: { "iss": "https://as.shop.example", "sub": "user_712", "aud": "https://shop.example", "client_id": "https://agent.example/shopping", "exp": 1776326800, "iat": 1776326740, "jti": "urn:uuid:9c0d8946-58f2-4d3a-b4e7-1c8a5d2f6b90", "authorization_details": [ { "type": "transaction_authority", "boundary": { "total_amount_limit": { "value": 200, "currency": "USD" }, "operations": ["ecommerce.search", "ecommerce.cart.add", "ecommerce.purchase"] } } ], "cnf": { "jkt": "NlSoUpSdoF0X-Br6xdK0UKbnj06kAs3oYSh9wg0efjM" } } Figure 3: ID-JAG issued for the delegated session Liu Expires 6 May 2027 [Page 20] Internet-Draft Scenario Discovery and Authorization November 2026 The cnf claim carries the thumbprint of the agent's DPoP key (Section 6.2); the authorization_details carry the approved instance, possibly narrowed from the proposed one by the AS and, in Mode A, possibly edited by the end user (Section 5.3). The agent never sees the end user's primary credentials in any mode; the only credential the agent holds is the token itself. A resource server verifies this token the same way whichever mode issued it, and MUST NOT behave differently based on any inference about how it was issued: the approved schema instance, not the issuance path, is the authorization. 5.2. Authorization Server Processing Requirements Whichever mode carries a session establishment request, the AS executes the same verification and policy evaluation pipeline before the token is issued. The pipeline applies across every mode: for Mode A, from the pushed authorization request through the code redemption; for the Mode B profiles, at the token request. Where a step is mode-specific, it references the mode that defines it: 1. Client authentication: The AS MUST authenticate the agent as the client of the request, with the methods of Section 6.1 among its options. 2. Key binding: The agent's DPoP key MUST be presented or registered with the request, and the issued token MUST be bound to it (Section 6.2). In Mode B2 the pending authorization is bound to this key at the moment the request is held (Section 5.4.2), so that the issued token reaches the agent that requested it, not the party that delivered the approval. 3. End user authentication: The request MUST be completed by an authentication of the end user. In Mode A the end user authenticates on the AS's authorization surface. In Mode B1 the subject_token is the identity assertion of the host-mediated interaction, produced with a host-native credential. In Mode B2 the AS obtains the assertion after the end user approves the pending request, with a credential the agent did not present (Section 5.4.2). In Mode B3 the assertion is one the agent already holds, subject to the freshness rule of Section 5.4.3. 4. Instance validation: The proposed schema instance MUST conform to the definition of its declared schema type, as required by [I-D.liu-oauth-authorization-schemas]; a nonconforming instance is an error of that framework. Liu Expires 6 May 2027 [Page 21] Internet-Draft Scenario Discovery and Authorization November 2026 5. Policy evaluation: The AS MUST review the proposed instance against its client registration metadata, its review policies, and the resource owner's consent, and MAY narrow the granted instance accordingly, without altering its semantic meaning ([I-D.liu-oauth-authorization-schemas]). The review is at the level of the proposed boundary, not of individual behaviors: per- behavior verification is the resource server's (Section 7.1). In Mode B3 the containment rule of Section 5.4.3 applies, and a widening request is routed to an interactive mode rather than issued silently. 6. Issuance: The AS issues the ID-JAG of Section 5.1 in the Mode B profiles, or the access token of the authorization code grant in Mode A: the end user as subject, the agent as client, authorization_details carrying the granted instance, bound to the agent's DPoP key, with a short lifetime and a jti unique among the tokens the AS issues. 5.3. Mode A: Front-Channel Establishment with Schema Annotation Mode A is a profile of the authorization code grant of [RFC6749] with Pushed Authorization Requests [RFC9126], PKCE [RFC7636], and Rich Authorization Requests [RFC9396]. It requires no host container: the authorization URI can reach the end user over any channel the deployment provides, which makes it the mode every conforming application supports and the only one always available to agents deployed outside the end user's device. 1. The agent constructs the proposed schema instance and pushes an authorization request to the AS's pushed authorization request endpoint. The authorization_details of the pushed request carry the proposed instance, and the request carries the agent's client authentication. 2. The agent hands the authorization URI to the host container or to the deployment's user channel. The end user opens the AS's authorization surface, authenticates with the AS, and reviews the proposed schema instance, rendered for the end user as authorization_details are rendered in [RFC9396] deployments. The consent surface is rendered by the AS, not by the agent. The end user MAY annotate the instance: adjusting the fields the AS exposes for end user editing, such as raising or lowering total_amount_limit or removing operations from the boundary. An annotation is a boundary the end user authored, not one the agent authored and the end user accepted. Liu Expires 6 May 2027 [Page 22] Internet-Draft Scenario Discovery and Authorization November 2026 3. The end user completes the interaction, and the AS issues an authorization code reflecting the approved instance. The code reaches the agent over the completion channel the deployment provides, a front-channel redirect through the host container, or a polling or pushed arrangement. The agent redeems the code at the token endpoint, authenticating as a client and presenting a DPoP proof [RFC9449]. 4. The token response carries the granted authorization_details. Because the end user may have annotated the instance, the granted details MAY differ from the proposed ones: the agent MUST read the granted instance before operating under it, and an agent that cannot operate under the granted boundary MUST NOT use the token and SHOULD report the divergence to the end user. The pushed authorization request of step 1 is, for a session with the application of Figure 1 whose proposed boundary limits purchases to 200 USD: POST /oauth2/par HTTP/1.1 Host: as.shop.example Content-Type: application/x-www-form-urlencoded response_type=code &client_id=https://agent.example/shopping &redirect_uri=https://agent.example/callback &code_challenge=(a challenge derived from the PKCE verifier) &code_challenge_method=S256 &authorization_details=(the schema instance proposed for the session, as a JSON array) Figure 4: Pushed authorization request carrying the proposed schema instance The AS returns a request_uri per [RFC9126]; the authorization URI handed to the user channel in step 2 is the AS's authorization endpoint with client_id and request_uri. Which fields of a schema instance a consent surface exposes to end user editing, and how annotations round-trip to agents, are open questions (Appendix B). Liu Expires 6 May 2027 [Page 23] Internet-Draft Scenario Discovery and Authorization November 2026 5.4. Mode B: Back-Channel Establishment under ID-JAG Mode B is the back-channel family: the agent drives the token endpoint directly, under the Identity Assertion JWT Authorization Grant [I-D.ietf-oauth-identity-assertion-authz-grant], with the mode advertised in establishment_modes_supported, at the token endpoint of an authorization server listed in authorization_servers, whose address the agent obtained from its AS metadata [RFC8414]. The token request is the same in all three profiles, and is specified in Section 5.4.1; the profiles differ in the timing of end user interaction: B1, host-mediated assertion: The end user interacts first: the host container opens an authorization interaction, the end user authenticates with a host-native credential and consents to the proposed schema instance, and the resulting identity assertion becomes the subject_token of the token request (Section 5.4.1). B2, pending approval: The token request comes first: the AS holds it pending, solicits the end user's approval, and issues the ID-JAG once the approval arrives (Section 5.4.2). B3, silent establishment: No fresh interaction: the agent holds a valid identity assertion, and the requested boundary is contained in what the end user already approved (Section 5.4.3). 5.4.1. Mode B1: Host-Mediated Assertion In Mode B1, the end user interacts before the token request: 1. The agent asks the host container to open an authorization interaction. The interaction surface is rendered by the host container or by the AS directly, not by the agent. The end user authenticates with a host-native credential, such as a passkey [WEBAUTHN] or platform biometric, and consents to the proposed schema instance. 2. The resulting identity assertion is presented to the AS as the subject of the ID-JAG request. The AS processes the request through the pipeline of Section 5.2: it authenticates the agent as the client, validates the assertion, and reviews the schema instance against its policies as required by [I-D.liu-oauth-authorization-schemas]. 3. The AS issues the ID-JAG, whose shape is the mode-independent one of Section 5.1. Liu Expires 6 May 2027 [Page 24] Internet-Draft Scenario Discovery and Authorization November 2026 4. The agent presents the ID-JAG, with a DPoP proof [RFC9449], on every structured call to the application, whether a direct API operation or an MCP tool call. The token request of step 2 is, for a session with the application of Figure 1 whose proposed boundary limits purchases to 200 USD: POST /oauth2/token HTTP/1.1 Host: as.shop.example Content-Type: application/x-www-form-urlencoded DPoP: eyJ... grant_type=urn:ietf:params:oauth:grant-type:token-exchange &requested_token_type=urn:ietf:params:oauth:token-type:id-jag &audience=https://shop.example &subject_token=eyJ... &subject_token_type=urn:ietf:params:oauth:token-type:id_token &authorization_details=(the schema instance proposed for the session, as a JSON array) Figure 5: ID-JAG token request for a delegated session The subject_token carries the identity assertion produced by the interaction of step 1; its format and validation follow [I-D.ietf-oauth-identity-assertion-authz-grant]. The agent authenticates at the token endpoint as a client (Section 6.1) and presents a DPoP proof. In Mode B2 the initial request carries no subject_token: the AS obtains the assertion after the end user approves the pending request (Section 5.4.2). In Mode B3 the assertion is one the agent already holds (Section 5.4.3). 5.4.2. Mode B2: Pending Approval In Mode B2, the interaction follows the request rather than preceding it. The agent posts the token request of Section 5.4.1 without a subject_token, with completion_mode set to deferred, as defined in the Deferred Token Response [I-D.ietf-oauth-deferred-token-response]. The AS validates the request as far as it can, creates a pending authorization, and returns the deferred response of that specification, carrying a deferral_code and a polling interval. The AS then solicits the end user's approval through a deployment-defined channel, such as a host container notification or a message to one of the end user's devices; the end user approves on the interaction surface, authenticating with a host-native credential or an equivalent platform mechanism; the AS thereupon obtains the identity assertion and resolves the deferred request. The agent retrieves the ID-JAG by polling the token endpoint with the deferral_code, or receives it at a registered deferred client notification endpoint, Liu Expires 6 May 2027 [Page 25] Internet-Draft Scenario Discovery and Authorization November 2026 and continues other work in the meantime. The carriage of the pending indication and the completion signal is that of [I-D.ietf-oauth-deferred-token-response], including the sender-constraining of the pending authorization to the agent's DPoP key (Section 10.1 of that specification) and the bounded lifetime and error reporting of a request that is denied or expires (Sections 5.4, 5.6, and 7). What this specification fixes are the properties any Mode B2 deployment MUST preserve on top of that carriage: 1. Instance fidelity: The approval surface MUST present the proposed schema instance, and the issued token carries that instance, possibly narrowed by the AS. 2. Approver authentication: The approval MUST authenticate the end user with a credential the agent did not present: a host-native credential or an equivalent platform mechanism. 5.4.3. Mode B3: Silent Establishment Mode B3 serves renewal and continuation: the end user interacted once, and sessions within the same boundary do not interrupt again. The agent posts the token request of Section 5.4.1 with an identity assertion it already holds or can obtain without user interaction. The AS MAY issue the ID-JAG without any fresh end user interaction, subject to three rules: 1. Freshness: The assertion MUST satisfy the AS's freshness policy for the schema instance being issued: an assertion acceptable at one assurance level does not silently authorize an instance that demands more. 2. Containment: The requested schema instance MUST be no wider than the instance the end user previously approved for the same end user, agent, application, and schema type, preserving the monotonic narrowing principle of [I-D.liu-oauth-authorization-schemas]. A widening request MUST NOT be issued silently: the AS routes it to Mode B1 or Mode B2. 3. Unchanged runtime enforcement: A silently established session is subject to exactly the same runtime enforcement and remediation semantics (Section 7) as any other: silence at issuance never implies silence at runtime. What granularity of prior consent suffices for containment, and how consent records age out, are open questions (Appendix B). Liu Expires 6 May 2027 [Page 26] Internet-Draft Scenario Discovery and Authorization November 2026 5.5. One Session, All Surfaces, One Primary Path A delegated session is honored across all of the application's surfaces without re-authentication of the end user, but the surfaces are not peers. Structured surfaces are the primary path for executing work; presentation surfaces are the secondary path for low- risk operations. Structured surfaces (primary path): The agent performs application work through structured calls: direct HTTP API operations, or tool calls through an MCP server the application exposes (Section 3.2). The agent presents its token in the Authorization header, with a DPoP proof, on every structured call. High-stakes operations, such as payment and booking, belong on this path: they are authorized by schema instances, verified at the resource server, and remediated through Section 7.2. Presentation surfaces (secondary path): The web and native application surfaces are for operations the end user is meant to see: browsing, inspecting results, and other low-risk interactions. Deployments SHOULD confine presentation-surface work to low-risk operations. An operation outside the approved boundary does not become presentation-surface work by moving it to a presentation surface, because the boundary is evaluated at the resource server, not at the surface. When the agent does use a presentation surface on the end user's behalf, the host container mediates the credentials: Web surface: The host container establishes a web session for the end user by exchanging the agent's token with the application, at the browser_session_endpoint of the web surface when the advertisement declares one, over the front channel or a back- channel defined by the deployment. The web credential that results, such as a session cookie, is set by and visible to the host container only. The agent MUST NOT be able to read, copy, or replay web session credentials. Concretely, where a cookie is used, it is stored in the host container's cookie store, scoped to the application's origin, and never exposed to agent code. Native application surface: The host container passes the agent's token to the target application over a local inter-process channel provided by the operating system. The receiving application validates the token as it would any other presented token. The channel MUST authenticate the receiving application as the one associated with the token's audience, using the operating system's application identity mechanisms. Liu Expires 6 May 2027 [Page 27] Internet-Draft Scenario Discovery and Authorization November 2026 The unification rule is one-directional: one delegated session covers all surfaces. It does not create any new authority: an operation performed on a presentation surface is still verified by the resource server against the approved schema instance, exactly as it would be on a structured surface. 6. Agent Identity and Token Binding 6.1. Agent Client Authentication The agent is an OAuth client, and the AS authenticates it at the token endpoint like any other client. Deployments that operate a SPIFFE trust domain that covers the agent MAY authenticate it with the SPIFFE client authentication methods of [I-D.ietf-oauth-spiffe-client-auth], verified against that domain's bundle, which the AS obtains out of band the way it obtains client registration metadata. A trust domain covers an agent in either shape: an agent running as a workload of the domain presents its own SVID, and a mobile agent obtains a short-lived SVID from an authority of its vendor's domain, typically the agent vendor's backend, after that backend has authenticated the installation. How the domain establishes the identity of the entities it covers is domain- internal: a vendor backend MAY run device risk control before issuing or renewing an SVID, and refusing renewal revokes the agent's client identity without involving the AS. An agent no trust domain covers authenticates with the client authentication of the underlying grant, as any other OAuth client. Two boundaries keep the composition clean. SPIFFE client authentication authenticates the agent as the client; the identity assertion of the Mode B profiles authenticates the end user as the subject: two different parties on the same request, evaluated independently. And whatever authenticates the client, every issued token remains DPoP-bound (Section 6.2): the spiffe client authentication is used at the token endpoint, never as a token binding. 6.2. DPoP Binding Every token this protocol issues MUST be DPoP-bound [RFC9449]: the AS records the agent's public key in the cnf claim, and the agent presents a fresh proof with every request, ID-JAG and access token alike, whichever mode issued it and whichever instance it carries. A token intercepted on the network or extracted from a log is therefore not replayable. 7. Runtime Enforcement and Remediation Liu Expires 6 May 2027 [Page 28] Internet-Draft Scenario Discovery and Authorization November 2026 7.1. Atomic Constraint Verification For every agent operation, the resource server answers the two-part question of [I-D.liu-oauth-authorization-schemas]: is the authorization bound to the token still active, and is this operation within its bounds? Before that, the presented token is validated as the JWT it is, per the rules of its issuer: signature, issuer, audience, expiration, and the DPoP proof of [RFC9449]. Whether the token is an ID-JAG or a conventional access token changes nothing in what follows. The verification is deterministic constraint evaluation against the approved schema instance, including the cumulative constraints and task-in-work evaluation defined there. This specification adds no new verification machinery at this layer. 7.2. Remediation Through Re-Establishment When an operation violates the approved boundary, the resource server refuses it with the reverse-guided error response of Section 5 of [I-D.liu-oauth-authorization-schemas]: the insufficient_authorization error code with a schema_profile_uri parameter dereferencing to a schema profile document, which describes machine-readably the authorization the refused operation requires: the schema type, the boundary constraints the required instance must carry, and, when the refusal is confirmation-covered, confirmation_required set. The HTTP status code follows the conventions of [RFC6750]: 401 when no valid token is presented, which is the session challenge of Section 3.3, and 403 when a valid token lacks the required authorization. When the deployment chooses not to offer remediation, the resource server denies the request with the plain error responses of the underlying specifications, and this specification states nothing further. For the session of Figure 3, an agent that attempts a 210 USD purchase under the 200 USD limit receives: HTTP/1.1 403 Forbidden WWW-Authenticate: Bearer error="insufficient_authorization", schema_profile_uri="https://shop.example/profiles/purchase" Content-Type: application/json { "error": "insufficient_authorization", "error_description": "Additional authorization is required for this purchase." } Figure 6: Refusal with remediation guidance for an out-of-bound purchase Liu Expires 6 May 2027 [Page 29] Internet-Draft Scenario Discovery and Authorization November 2026 Whether the refusal is confirmation-covered is decided at runtime by the authorization server and expressed in the schema profile: when the profile sets confirmation_required, the refusal is how the resource server communicates the need, and the user interaction of the establishment mode is where the end user satisfies it. For an operation within the approved boundary that the profile covers by confirmation, the required instance is the approved one; for an operation that exceeds the boundary, the profile constrains the minimal widening. The remediation is re-establishment, following the adaptive behavior of Section 5.6 of [I-D.liu-oauth-authorization-schemas]: the agent fetches the profile document, constructs the required schema instance, and requests it through an establishment mode of Section 5, exactly as it established the session. Four properties govern the composition: 1. Agent suspension: An agent that receives a remediable refusal MUST suspend the affected task: it MUST NOT retry the refused operation with the original token, and MUST NOT silently continue other work that depends on it. An agent that cannot or will not obtain the required instance reports the condition to the end user and terminates the task. 2. Mode conformance: The mode the agent runs must match what the profile demands. A confirmation-covered refusal requires a mode whose user interaction collects the end user's confirmation: Mode A, Mode B1, or Mode B2. Mode B2 fits the asynchronous case exactly: the agent sends the token request with completion_mode=deferred [I-D.ietf-oauth-deferred-token-response], the AS solicits the end user's approval out of band, and the agent polls or receives the callback per that specification while it continues other work. Mode B3 remains available only when the containment rule of Section 5.4.3 holds, which a widening never does. 3. Narrow re-issuance: The agent SHOULD request the minimal instance the profile describes, scoped to the refused operation; the AS reviews the proposal through the pipeline of Section 5.2 and SHOULD keep the issued token narrow, with a lifetime on the order of minutes. Deployments MAY make the remediation token single- use by rejecting a second presentation of its jti. 4. Retry semantics: The agent retries exactly the refused operation with the remediation token and a fresh DPoP proof, over the same structured surface as the refused call, and then continues its chain with the original token: the remediation token widens nothing else. The resource server accepts the retry through the Liu Expires 6 May 2027 [Page 30] Internet-Draft Scenario Discovery and Authorization November 2026 ordinary verification of Section 7.1: the retry succeeds because the presented instance is the required one, not because of any resume state. A resource server that wants to declare the exact widening rather than accept an agent-proposed instance MAY serve a request-specific profile document: the schema_profile_uri of the refusal can reference the refused request, so the profile it returns describes the minimal instance that request requires. An agent that repeatedly triggers remediable refusals for the same session is a signal, not an attack: the AS MAY decline further remediation issuances for the session, in which case the agent MUST treat the condition as a final refusal for the session. 8. Security Considerations 8.1. Credential Isolation The protocol's credential story is one sentence: the agent holds exactly one credential, the DPoP-bound token, and nothing else. The end user's primary credentials, the web session credentials, and the native inter-process channel credentials all live in the host container. Implementations MUST NOT expose web session cookies, platform credential stores, or inter-process channel handles to agent code, and MUST NOT design host container APIs that would let agent code enumerate or copy them. A deployment that cannot enforce this isolation MUST NOT enable the web and native surfaces of Section 5.5. 8.2. Establishment Mode Equivalence The four modes differ in when the end user interacts and in what the agent authenticates with, and they must not differ in what an attacker gains: Liu Expires 6 May 2027 [Page 31] Internet-Draft Scenario Discovery and Authorization November 2026 +============+============================+=========================+ | Mode | End user interaction | Agent authentication at | | | | issuance | +============+============================+=========================+ | A (Section | on the AS consent | pushed request and code | | 5.3) | surface; may annotate | redemption, with client | | | the instance | authentication and PKCE | +------------+----------------------------+-------------------------+ | B1 | host-native | client authentication | | (Section | credential, before | and DPoP at the token | | 5.4.1) | the token request | endpoint | +------------+----------------------------+-------------------------+ | B2 | approval of a pending | client authentication | | (Section | request, after the | and DPoP at the token | | 5.4.2) | token request | endpoint | +------------+----------------------------+-------------------------+ | B3 | none | client authentication | | (Section | | and DPoP at the token | | 5.4.3) | | endpoint | +------------+----------------------------+-------------------------+ Table 1 Three invariants hold across all modes. The end user's primary credentials are presented to the AS or to the host container, never to the agent. The issued token is DPoP-bound (Section 6.2) in every mode, so a stolen token is equally non-replayable regardless of how it was obtained. And the establishment mode is not an authorization input: the resource server MUST NOT accept or reject operations based on any inference about how the token was issued, because the approved schema instance, not the issuance path, is the authorization. Each mode carries its own residual risk. In Mode A the granted instance may differ from the proposed one, and an agent that ignores the granted authorization_details operates outside what the end user approved. In Mode B2 a pending authorization is a standing target for approval spoofing, bounded by the binding rules of Section 5.4.2. In Mode B3 the containment rule is the only barrier between renewal and silent widening, which is why a widening request MUST be rerouted to an interactive mode. Liu Expires 6 May 2027 [Page 32] Internet-Draft Scenario Discovery and Authorization November 2026 8.3. Remediation Guidance Authenticity The remediation of Section 7.2 routes the end user to the consent or approval surface of an establishment mode, rendered by the AS or by the host container, never by the agent. The trust in that surface is the trust the underlying specifications already define: the AS's origin, its TLS certificate, and its authentication of the end user. The one new pointer this protocol introduces is the schema profile document of the refusal, which an attacker able to serve a forged copy could use to steer the agent toward a wider instance than the operation needs, or toward an authorization server the application did not list. Agents MUST fetch the profile over TLS, MUST cross- check its auth_server value against the authorization_servers of the capability advertisement, and MUST reject mismatches; the narrow re- issuance of Section 7.2 bounds what a successfully misled agent can obtain. Residual risk remains: an end user who confirms without reading confirms what is on the surface. Deployments SHOULD design consent surfaces that make the material facts of the refused operation prominent. 8.4. Confirmation Fatigue Confirmations that are demanded frequently train the end user to confirm mechanically. Authorization servers SHOULD calibrate which refusals they mark confirmation_required so that confirmations are rare enough to remain meaningful, and SHOULD NOT demand confirmation for operations the deployment considers routine. The AS-side rate consideration of Section 7.2 is the complementary control: unlimited remediation for one session is not an entitlement. 8.5. Token Lifetime and Revocation The issued tokens are short-lived JWTs; their exposure window is bounded by their lifetime, and DPoP binding makes interception non- replayable. Remediation tokens issued for a refused operation carry the widened or re-confirmed boundary, so their lifetime SHOULD be minutes and they SHOULD be single-operation: an implementation SHOULD reject a second use of the same remediation token jti. All tokens of a session are revoked with the session: when the delegated session ends, by withdrawal, termination, or expiry, the AS MUST revoke the remediation tokens issued under it, and the resource server treats further remediation attempts as final refusals. Liu Expires 6 May 2027 [Page 33] Internet-Draft Scenario Discovery and Authorization November 2026 8.6. Advertisement Integrity The capability document steers agent planning and defines the open set of flows and operations. An attacker able to serve a forged document can steer agents toward attacker-chosen surfaces or away from flows the application actually opens. The web-surface document inherits HTTPS origin protection: the agent-capabilities well-known of Section 4.1 is fetched over authenticated TLS under the origin it is authentic for, and an agent SHOULD verify that the origin serving the document matches the document's resource. For the packaged copy of native applications, integrity rests on the application package's own signature and the platform's associated-domain verification; a device with a compromised package verification mechanism compromises the packaged copy, which is why Section 4.2 requires the origin- served copy to win every conflict. The well-known location adds a deployment risk that a purpose-built endpoint does not: administrators are frequently unaware of the .well-known path, as [RFC8615] observes, and an attacker who gains write access to an origin's static content can place or replace the document there without any visible change to the application, steering every agent that discovers the origin afterwards. Deployments SHOULD treat the capability document as part of the application's release surface, under the change control that governs the code serving it. The service members are display data, not identity claims. An agent MUST NOT treat a display name, logo, or policy URI as proof of which application it is interacting with; the binding is the resource origin and the authenticated channel the document arrived through. Consent and confirmation surfaces SHOULD pair the display name with the origin, so that the end user approves an origin, not a string an attacker chose. Phishing by display name is otherwise indistinguishable from a legitimate advertisement. 8.7. Native Surface Launch The app_link of a native_app platform entry is a launch address, and on today's mobile platforms most such addresses are custom scheme URIs, which carry no verification: any installed application can register any scheme, so a malicious application can attempt to intercept the launch and pose as the target. The protocol bounds this in three ways. On Android, a host container SHOULD launch by explicit intent targeting the declared package, which no scheme registration can intercept (Section 4.2). Session credentials are never carried in the link URI: they travel over the host platform's secure channel (Section 8.1). And where a handoff must travel through a URL, it carries a short-lived, single-use reference Liu Expires 6 May 2027 [Page 34] Internet-Draft Scenario Discovery and Authorization November 2026 redeemable at the application, so that an interception captures, at most, an expiring reference bound to one handoff, never a reusable session credential. When the application is not installed, the fallback is the web surface of the same application, not a download prompt an attacker can fake. 8.8. Privacy Considerations The capability advertisement is public by design and SHOULD NOT contain personal data. The authorization_details of the issued token travel with the token and are visible to anyone who can decode it, as in [RFC9396]; deployments SHOULD follow the instance-content privacy guidance of [I-D.liu-oauth-authorization-schemas]. The error descriptions of the remediation flow are shown to the end user and logged by intermediaries; they SHOULD state the triggered condition without unrelated personal data. Schema profile documents are public descriptions of required authorization and SHOULD NOT contain personal data. 9. IANA Considerations 9.1. Well-Known URI Registration This specification requests registration of the 'agent-capabilities' well-known URI in the "Well-Known URIs" registry established by [RFC8615]: URI suffix: agent-capabilities Change Controller: IETF Specification Document(s): Section 4.1 of this document Status: permanent Related information: The capability document advertises the scenario flows an application opens to agents, the surfaces a session attaches over, and the authorization pointers for each flow. Its subject is the application, not an agent; the 'agent-card.json' well-known registered for [A2A] describes an agent. The two documents are separate and MAY both be served under one origin (Section 4.3). Security considerations for the location are in Section 8.6 of this document. Liu Expires 6 May 2027 [Page 35] Internet-Draft Scenario Discovery and Authorization November 2026 9.2. OAuth Protected Resource Metadata Registration This specification requests registration of the following attribute in the "OAuth Protected Resource Metadata" registry established by [RFC9728]: Metadata Name: agent_capabilities_uri Metadata Description: HTTPS URL of the application's capability document, the standalone JSON document defined by this specification that advertises the application's scenaric flows, invocation and presentation surfaces, and authorization pointers to agents. Defined in Section 4.1 of this document. Change Controller: IETF Specification Document: Section 4.1 of this document 9.3. Agent Capability Document Fields Registry The capability document is a standalone JSON document defined by this specification. To allow controlled extension by future specifications, this specification requests the creation of a registry named "Agent Capability Document Fields" with a registration policy of Specification Required [RFC8126]. A registration carries a field name, a description, a Change Controller, and a Specification Document. The initial registrations are: Liu Expires 6 May 2027 [Page 36] Internet-Draft Scenario Discovery and Authorization November 2026 +=================================+===========================+ | Field Name | Description | +=================================+===========================+ | service | Display data describing | | | the application | +---------------------------------+---------------------------+ | resource | HTTPS origin of the | | | application | +---------------------------------+---------------------------+ | authorization_servers | Authorization server | | | issuer URLs | +---------------------------------+---------------------------+ | establishment_modes_supported | Establishment modes | | | accepted for the resource | +---------------------------------+---------------------------+ | authorization_schemas_supported | Schemas accepted in | | | authorization_details | +---------------------------------+---------------------------+ | scenaric_flows_supported | Composite flows opened to | | | agents | +---------------------------------+---------------------------+ | invocation_surfaces_supported | Surfaces an agent can act | | | through | +---------------------------------+---------------------------+ Table 2: Initial registrations, Agent Capability Document Fields Every initial registration has Change Controller IETF and Specification Document Section 3.1 of this document. 9.4. Agent Establishment Mode Identifiers The establishment_modes_supported field of the capability document names the establishment modes an application opens to agents, and the establishment_modes member of a scenaric flow narrows them. This specification requests the creation of a registry named "Agent Establishment Mode Identifiers" with a registration policy of Specification Required [RFC8126]. A registration carries a mode identifier, a description, a Change Controller, and a Specification Document. The initial registrations are: Liu Expires 6 May 2027 [Page 37] Internet-Draft Scenario Discovery and Authorization November 2026 +================+=======================================+ | Mode | Description | | Identifier | | +================+=======================================+ | par | Front-channel establishment with | | | Pushed Authorization Requests, in | | | which the end user reviews and may | | | annotate the proposed schema instance | +----------------+---------------------------------------+ | id-jag | Back-channel establishment with host- | | | mediated user interaction preceding | | | the token request | +----------------+---------------------------------------+ | id-jag-pending | Back-channel establishment in which | | | the authorization server holds the | | | token request pending and solicits | | | the end user's approval | +----------------+---------------------------------------+ | id-jag-silent | Back-channel establishment without | | | fresh user interaction, subject to | | | assertion freshness and prior-consent | | | containment | +----------------+---------------------------------------+ Table 3: Initial registrations, Agent Establishment Mode Identifiers Every initial registration has Change Controller IETF. The Specification Document is Section 5.3, Section 5.4.2, and Section 5.4.3 of this document for par, id-jag-pending, and id-jag- silent; for id-jag it is [I-D.ietf-oauth-identity-assertion-authz-grant], which defines the grant, profiled in Section 5.4.1 of this document. These identifiers name establishment modes of this specification's discovery layer. They are not OAuth parameters, and this specification requests no registration in the "OAuth Parameters" registry [RFC6749]. Each mode runs over an existing OAuth grant: the grant type of par is authorization_code, and the grant type of id- jag, id-jag-pending, and id-jag-silent is urn:ietf:params:oauth:grant-type:token-exchange. Authorization server support for those grants is advertised in the authorization server's own metadata, in grant_types_supported [RFC8414] and, for the ID-JAG modes, in authorization_grant_profiles_supported, in which urn:ietf:params:oauth:grant-profile:id-jag is registered by [I-D.ietf-oauth-identity-assertion-authz-grant]. Liu Expires 6 May 2027 [Page 38] Internet-Draft Scenario Discovery and Authorization November 2026 9.5. Agent Surface Types Registry This specification requests creation of a registry for the surface types used in invocation_surfaces_supported, named "Agent Surface Types", with a registration policy of Specification Required [RFC8126]. A registration carries a type name, a description, a Change Controller, and a Specification Document. The initial registrations are: +============+==========================================+ | Type Name | Description | +============+==========================================+ | http_api | A direct HTTP API of the application, | | | addressed by its base URL | +------------+------------------------------------------+ | mcp | An MCP server of the application, | | | addressed by its URL | +------------+------------------------------------------+ | web | The web presentation surface, addressed | | | by its browser_session_endpoint | +------------+------------------------------------------+ | native_app | A packaged native application associated | | | with the application's origin, addressed | | | by its associated_origin | +------------+------------------------------------------+ Table 4: Initial registrations, Agent Surface Types Every initial registration has Change Controller IETF and Specification Document Section 3.1 of this document. 10. References 10.1. Normative References [I-D.ietf-oauth-deferred-token-response] de Oliveira Niero, G. and D. Liu, "Deferred Token Response", Work in Progress, Internet-Draft, draft-ietf- oauth-deferred-token-response-01, 31 October 2026, . Liu Expires 6 May 2027 [Page 39] Internet-Draft Scenario Discovery and Authorization November 2026 [I-D.ietf-oauth-identity-assertion-authz-grant] Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz- grant-06, 30 October 2026, . [I-D.ietf-oauth-spiffe-client-auth] Schwenkschuster, A., Kasselman, P., Rose, S., Thorgersen, S., and N. Cam-Winget, "OAuth SPIFFE Client Authentication", Work in Progress, Internet-Draft, draft- ietf-oauth-spiffe-client-auth-02, 15 June 2026, . [I-D.liu-oauth-authorization-schemas] Liu, D., Sheffer, Y., Zehavi, Y., and S. Krishnan, "Domain-Specific Authorization Schemas for OAuth 2.0", Work in Progress, Internet-Draft, draft-liu-oauth- authorization-schemas-01, 2 November 2026, . [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, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Liu Expires 6 May 2027 [Page 40] Internet-Draft Scenario Discovery and Authorization November 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . 10.2. Informative References [A2A] A2A Protocol Working Group, "Agent2Agent (A2A) Protocol Specification", . [APPLINKS] Google, "Android App Links", . Liu Expires 6 May 2027 [Page 41] Internet-Draft Scenario Discovery and Authorization November 2026 [I-D.ietf-webbotauth-httpsig-protocol] Meunier, T. and S. Major, "HTTP Message Signatures for automated traffic", Work in Progress, Internet-Draft, draft-ietf-webbotauth-httpsig-protocol-01, 29 October 2026, . [MCP] Model Context Protocol Project, "Model Context Protocol Specification, 2025-06-18 revision", . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9727] Smith, K., "api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs", RFC 9727, DOI 10.17487/RFC9727, June 2025, . [UNIVLINKS] Apple Inc., "Supporting associated domains", . [WEBAUTHN] World Wide Web Consortium, "Web Authentication: An API for accessing Public Key Credentials, Level 3", . Appendix A. Complete End-to-End Use Case: Booking a Flight _This appendix is non-normative._ The end user says: "book me the cheapest flight to Shanghai tomorrow, but nothing above 5000 USD without asking me." The agent runs on the end user's phone, inside the operating system's host container. A.1. Discovery and Matching The agent has no prior relationship with the airline application. It fetches https://airline.example/.well-known/agent-capabilities and reads the capability document: the application supports the travel_booking schema and composes it into a find-and-book scenaric flow. Liu Expires 6 May 2027 [Page 42] Internet-Draft Scenario Discovery and Authorization November 2026 The agent matches the instruction to the find-and-book flow and plans the session request: a travel_booking instance whose boundary sets total_amount_limit to 200 USD for the search-and-book work, with the end user's 5000 USD ceiling recorded as the outer bound the agent will seek confirmation for, at most once, if the cheapest acceptable flight exceeds 200 USD. A.2. Session Establishment Holding the capability document, the agent proceeds directly to establishment, without any call being refused first. It drives session establishment under Mode B1 (Section 5.4.1): the host container renders the AS interaction surface, the end user authenticates with the phone's platform biometric, sees the proposed booking boundary (search, hold, and book, total limit 200 USD this session), and confirms. The agent authenticates as a client at the token request. The AS issues the DPoP-bound ID-JAG. A.3. Within Bounds The agent searches flights and holds the cheapest one, 480 USD, presenting the ID-JAG with a DPoP proof on every call. The resource server verifies each operation against the approved instance; all are within bounds; no interaction is triggered. A.4. The Refusal Prices move: the held fare expires, and the cheapest available flight within the end user's constraints is 4980 USD. The agent attempts the booking. The operation exceeds the approved 200 USD boundary, so the resource server refuses it with the reverse-guided error of Section 7.2: 403 with insufficient_authorization and a schema_profile_uri referencing a profile that describes the authorization required for the booking: the travel_booking type, a boundary.total_amount_limit covering 4980 USD, and boundary.operations covering travel.book, with confirmation_required set, because the booking widens beyond the approved limit. The agent suspends the affected task. It does not retry with the session token, and it does not silently substitute a different flight. It fetches the profile, constructs the required instance, and requests it through Mode B1: the host container opens the AS interaction surface, the end user authenticates with the phone's platform biometric and sees the flight, the fare, and the triggered condition, and confirms. The AS issues a remediation token narrow to the confirmed booking, carrying the required widening: Liu Expires 6 May 2027 [Page 43] Internet-Draft Scenario Discovery and Authorization November 2026 { "iss": "https://as.airline.example", "sub": "user_712", "aud": "https://airline.example", "client_id": "https://agent.example/travel", "exp": 1776327260, "iat": 1776326940, "jti": "urn:uuid:6bb9c2a4-6f0e-4c1d-9b3f-2e7a8c5d4e1f", "authorization_details": [ { "type": "travel_booking", "boundary": { "total_amount_limit": { "value": 4980, "currency": "USD" }, "operations": ["travel.book"] } } ], "cnf": { "jkt": "NlSoUpSdoF0X-Br6xdK0UKbnj06kAs3oYSh9wg0efjM" } } Figure 7: Remediation token issued after end user confirmation A.5. The Retry The agent retries exactly the refused booking with the remediation token and a fresh DPoP proof: POST /api/bookings HTTP/1.1 Host: airline.example Authorization: Bearer eyJ... DPoP: eyJ... Content-Type: application/json { "flight_id": "MU5100-20261016", "amount": { "value": 4980, "currency": "USD" } } Figure 8: Retry of the refused booking with the remediation token Liu Expires 6 May 2027 [Page 44] Internet-Draft Scenario Discovery and Authorization November 2026 The resource server verifies the retried request against the presented instance as it verifies every request, and executes the booking: the retry succeeds because the instance is the required one, not because of any resume state. The agent's chain continues with the confirmed booking as its result, and it continues with the original ID-JAG for everything else, such as retrieving the itinerary. The payment never moves to a presentation surface: the confirmation happens on the consent surface of the establishment mode, and the booking executes on the structured path, as an agent call carrying the remediation token. Presentation surfaces in this deployment carry the low-risk parts of the session, such as the end user browsing the itinerary, and nothing else. A.6. The Audit Trail Afterwards, the record of what happened is reconstructable from protocol objects: the capability advertisement declared the open operations before anything ran; the ID-JAG's authorization_details record the approved boundary; the refusal's schema profile document and the remediation token's instance record exactly what was refused and what the end user then approved; and the DPoP proofs tie every call to the agent's key. Nothing in this trail depends on the agent's goodwill. Appendix B. Open Issues _This appendix is non-normative; it records questions on which working group guidance is sought._ Stale Packaged Advertisements For native applications, Section 4.2 resolves conflicts between the packaged and origin-served advertisements in favor of the latter, checked before the first remote operation of a session. Whether finer-grained freshness signals, such as advertisement version numbers carried in session responses, are warranted is an open question. Silent Establishment Consent Records Mode B3 issues tokens against a prior consent record whose granularity is not yet fixed: whether containment is evaluated per schema type, per flow, or per exact instance; how consent records expire relative to assertion freshness; and whether the advertisement can signal which modes an authorization server will service silently for a given schema. Liu Expires 6 May 2027 [Page 45] Internet-Draft Scenario Discovery and Authorization November 2026 Mode A Annotation Scope Which fields of a schema instance the Mode A consent surface exposes for end user editing, how annotations are presented so that the end user understands the boundary being authored, and the exact round trip of the granted instance to the agent, need profiling work. Mode B2 Approval Solicitation The completion carriage of Mode B2 is defined by [I-D.ietf-oauth-deferred-token-response]. Which channels an authorization server uses to reach the end user for a pending approval, and whether the capability advertisement should be able to declare which channels an application's authorization servers will use, remain open. Web Session Exchange The browser_session_endpoint of the web surface (Section 3.1) is where the host container exchanges the agent's token for a web session credential (Section 5.5). The request and response format of that exchange is deployment-defined today. Whether this specification should fix it, for example as a POST of the agent's token answered with a session cookie scoped to the application's origin, and how the exchange proves the host container's mediation to the application, are open questions. Acknowledgments The author thanks Hongru Zhu, Hui Xue, and Suresh Krishnan for enlightening discussions. Author's Address Dapeng Liu Alibaba Email: max.ldp@alibaba-inc.com Liu Expires 6 May 2027 [Page 46]