Scenario-Based Service Discovery and Authorization Protocol in Agent Environments

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" }
    },
    {
      "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"]
    }
  ],
  "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"
    }
  ]
}

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 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.¶

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.¶

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.¶

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.¶

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]:¶

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."
}

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.¶

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.¶

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.¶

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.¶

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.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"
  }
}

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.¶

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.¶

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)

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).¶

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).¶

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)

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.¶

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.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.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."
}

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 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.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:¶

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.¶

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.¶

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 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.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.¶

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:¶

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:¶

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].¶

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:¶

Every initial registration has Change Controller IETF and Specification Document Section 3.1 of this document.¶

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, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-deferred-token-response-01>.

[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, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-06>.

[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, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-spiffe-client-auth-02>.

[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, <https://datatracker.ietf.org/doc/html/draft-liu-oauth-authorization-schemas-01>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/rfc/rfc6750>.

[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, <https://www.rfc-editor.org/rfc/rfc7636>.

[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, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.

[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, <https://www.rfc-editor.org/rfc/rfc8693>.

[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, <https://www.rfc-editor.org/rfc/rfc9126>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[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, <https://www.rfc-editor.org/rfc/rfc9449>.

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/rfc/rfc9728>.

10.2. Informative References

[A2A]

A2A Protocol Working Group, "Agent2Agent (A2A) Protocol Specification", <https://a2a-protocol.org/latest/specification/>.

[APPLINKS]

Google, "Android App Links", <https://developer.android.com/training/app-links>.

[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, <https://datatracker.ietf.org/doc/html/draft-ietf-webbotauth-httpsig-protocol-01>.

[MCP]

Model Context Protocol Project, "Model Context Protocol Specification, 2025-06-18 revision", <https://modelcontextprotocol.io/specification/2025-06-18>.

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

[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, <https://www.rfc-editor.org/rfc/rfc9727>.

[UNIVLINKS]

Apple Inc., "Supporting associated domains", <https://developer.apple.com/documentation/xcode/supporting-associated-domains>.

[WEBAUTHN]

World Wide Web Consortium, "Web Authentication: An API for accessing Public Key Credentials, Level 3", <https://www.w3.org/TR/webauthn-3/>.

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.¶

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:¶

{
  "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"
  }
}

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" }
}

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.¶

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.¶

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.¶