]> Alibaba

max.ldp@alibaba-inc.com

OAuth AI Agents Service Discovery Scenario-Based Authorization Protected Resource Metadata ID-JAG DPoP 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.

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

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 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 and the Identity Assertion JWT Authorization Grant (ID-JAG) , with pending delivery under ; the issued tokens are sender-constrained with DPoP and carry their boundaries in authorization_details ; and runtime verification and remediation run on the authorization schemas framework . 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. 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.

Terminology and Architecture Overview This specification uses the terms "authorization server" (AS), "client", "resource server" (RS), and "access token" defined in , the authorization_details structure defined in , and the DPoP binding defined in . Where the capability document reuses the resource and authorization_servers field names of the Protected Resource Metadata , 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 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) 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 obtains delegated authorization for an end user, one of the modes defined in 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 ().

Authorization Schema:

A domain-specific authorization schema as defined in : 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.

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.

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 . 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 (). 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 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 . 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:

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

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

url:

REQUIRED for the http_api and mcp types. The base URL of the HTTP API or of the 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 ) and sender_constraint (OPTIONAL; the sender-constraining mechanism; this specification defines dpop, ). 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 ().

associated_origin:

REQUIRED for the native_app type. The HTTPS origin whose well-known advertisement the packaged copy mirrors ().

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 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 : the agent fetches each issuer's AS metadata document 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 () 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 (). 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 (). 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 , 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 . 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 ; 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 .

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

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 , 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 when it is scope-based. The response also carries the resource_metadata parameter of :

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 (). 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 . 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 (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 () 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 (). Nothing in this step is specific to this protocol beyond the document the chain leads to.

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 () and establishment mode selection (); the 401 challenge of 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 . 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 , and change nothing in , , or .

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: The location is guessable in the manner of the AS metadata well-known of : 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 : 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 (); an agent that finds the two in disagreement holds no advertisement for that origin (). 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 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 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 ().

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 and Universal Links . 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 (). Native-surface session establishment runs over the same local inter-process channel, using the host platform's secure credential passing; the channel requirements of apply.

Relationship to Existing Discovery Mechanisms An origin may serve several discovery artifacts at once. AS metadata and Protected Resource Metadata 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 (). API catalogs 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 , 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 , at the http-message-signatures-directory well-known that specification requests, identifies the agent as the caller: the agent signs the request with , 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.

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 , and the Mode B family runs the Identity Assertion JWT Authorization Grant (ID-JAG) . 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 , 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 (), then the modes in two families. Mode A () 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 () is the back-channel family under the Identity Assertion JWT Authorization Grant (ID-JAG) , 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 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.

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 . Mode A instead issues the access token of the authorization code grant of . 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 whose approved boundary limits purchases to 200 USD:

ID-JAG issued for the delegated session

The cnf claim carries the thumbprint of the agent's DPoP key (); 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 (). 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.

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 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 (). In Mode B2 the pending authorization is bound to this key at the moment the request is held (), 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 (). In Mode B3 the assertion is one the agent already holds, subject to the freshness rule of .
4. Instance validation: The proposed schema instance MUST conform to the definition of its declared schema type, as required by ; 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 (). The review is at the level of the proposed boundary, not of individual behaviors: per-behavior verification is the resource server's (). In Mode B3 the containment rule of applies, and a widening request is routed to an interactive mode rather than issued silently.
6. Issuance: The AS issues the ID-JAG of 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.

Mode A: Front-Channel Establishment with Schema Annotation Mode A is a profile of the authorization code grant of with Pushed Authorization Requests , PKCE , and Rich Authorization Requests . 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 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 .
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 whose proposed boundary limits purchases to 200 USD:

Pushed authorization request carrying the proposed schema instance

The AS returns a request_uri per ; 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 ().

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 , 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 . The token request is the same in all three profiles, and is specified in ; 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 ().

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

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

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 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 : it authenticates the agent as the client, validates the assertion, and reviews the schema instance against its policies as required by .
3. The AS issues the ID-JAG, whose shape is the mode-independent one of .
4. The agent presents the ID-JAG, with a DPoP proof , 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 whose proposed boundary limits purchases to 200 USD:

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 . The agent authenticates at the token endpoint as a client () 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 (). In Mode B3 the assertion is one the agent already holds ().

Mode B2: Pending Approval In Mode B2, the interaction follows the request rather than preceding it. The agent posts the token request of without a subject_token, with completion_mode set to deferred, as defined in the 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, and continues other work in the meantime. The carriage of the pending indication and the completion signal is that of , 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.

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

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

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.

Agent Identity and Token Binding

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 , 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 (): the spiffe client authentication is used at the token endpoint, never as a token binding.

DPoP Binding Every token this protocol issues MUST be DPoP-bound : 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.

Runtime Enforcement and Remediation

Atomic Constraint Verification For every agent operation, the resource server answers the two-part question of : 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 . 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.

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 : 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 : 401 when no valid token is presented, which is the session challenge of , 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 , an agent that attempts a 210 USD purchase under the 200 USD limit receives:

Refusal with remediation guidance for an out-of-bound 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 : the agent fetches the profile document, constructs the required schema instance, and requests it through an establishment mode of , 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 , 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 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 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 : 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.

Security Considerations

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 .

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:

Mode	End user interaction	Agent authentication at issuance
A ()	on the AS consent surface; may annotate the instance	pushed request and code redemption, with client authentication and PKCE
B1 ()	host-native credential, before the token request	client authentication and DPoP at the token endpoint
B2 ()	approval of a pending request, after the token request	client authentication and DPoP at the token endpoint
B3 ()	none	client authentication and DPoP at the token endpoint

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

Remediation Guidance Authenticity The remediation of 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 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.

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 is the complementary control: unlimited remediation for one session is not an entitlement.

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.

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

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 (). Session credentials are never carried in the link URI: 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, 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.

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 ; deployments SHOULD follow the instance-content privacy guidance of . 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.

IANA Considerations

Well-Known URI Registration This specification requests registration of the 'agent-capabilities' well-known URI in the "Well-Known URIs" registry established by :

URI suffix:

agent-capabilities

Change Controller:

IETF

Specification Document(s):

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 describes an agent. The two documents are separate and MAY both be served under one origin (). Security considerations for the location are in of this document.

OAuth Protected Resource Metadata Registration This specification requests registration of the following attribute in the "OAuth Protected Resource Metadata" registry established by :

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 of this document.

Change Controller:

IETF

Specification Document:

of this document

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 . A registration carries a field name, a description, a Change Controller, and a Specification Document. The initial registrations are: Initial registrations, Agent Capability Document Fields

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

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

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 . A registration carries a mode identifier, a description, a Change Controller, and a Specification Document. The initial registrations are: Initial registrations, Agent Establishment Mode Identifiers

Mode Identifier	Description
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

Every initial registration has Change Controller IETF. The Specification Document is , , and of this document for par, id-jag-pending, and id-jag-silent; for id-jag it is , which defines the grant, profiled in 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 . 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 and, for the ID-JAG modes, in authorization_grant_profiles_supported, in which urn:ietf:params:oauth:grant-profile:id-jag is registered by .

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 . A registration carries a type name, a description, a Change Controller, and a Specification Document. The initial registrations are: Initial registrations, Agent Surface Types

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

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

References Normative References This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. Okta Independent Ping Identity This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using OAuth 2.0 Token Exchange (RFC 8693) and the JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523). This pattern is informally referred to as Cross-App Access (XAA). Itaú Alibaba Group This document defines the Deferred Token Response (DTR) extension for OAuth 2.1. In existing OAuth grants, the token endpoint either issues an access token or returns an error. DTR establishes a generic asynchronous token request mechanism that any OAuth grant may plug into. In DTR-aware flows, the authorization server returns a deferral_code and a polling interval, indicating that the final token response will be available at a later time. The client retrieves the eventual response by polling the token endpoint, or by receiving a callback from the authorization server when one is configured. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. Alibaba Independent Raiffeisen Bank International Cisco This specification defines a framework for constructing fine-grained authorization requests in OAuth 2.0 using domain-specific authorization schemas: structured definitions of behavioral boundaries for a particular application domain. Schema instances are carried in authorization requests via authorization_details; upon approval, the instance governs the authorization associated with the issued access token. Approved instances have a lifecycle: they become active upon approval and end, with defined protocol consequences for token issuance, refresh, and resource access. Resource servers verify client behaviors against the approved schema instance at runtime through deterministic constraint evaluation. Authorization servers review requested schema instances against server-side authorization policies. This specification also defines a negotiation pattern, reverse-guided authorization, allowing resource servers to reference a schema profile in error responses, guiding clients toward the authorization required for their next action. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). Defakto Security Defakto Security NIST IBM Cisco Systems This specification profiles the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521], the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523], and OAuth 2.0 Attestation-Based Client Authentication [I-D.draft-ietf-oauth-attestation-based-client-auth] to enable the use of SPIFFE Verifiable Identity Documents (SVIDs) as client credentials in OAuth 2.0. It defines how OAuth clients with SPIFFE credentials can authenticate to OAuth authorization servers using their JWT-SVIDs, WIT-SVIDs, or X.509-SVIDs without the need for client secrets. This approach enhances security by enabling seamless integration between SPIFFE-enabled workloads and OAuth authorization servers while eliminating the need to distribute and manage shared secrets such as static client secrets. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References Model Context Protocol Project A2A Protocol Working Group World Wide Web Consortium Google Apple Inc. This document defines the "api-catalog" well-known URI and link relation. It is intended to facilitate automated discovery and usage of published Application Programming Interfaces (APIs). A request to the api-catalog resource will return a document providing information about, and links to, the Publisher's APIs. Cloudflare Google This document describes a protocol for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. It defines the Signature-Agent header field for in-band key discovery, a key directory format based on JWKS, and a well-known URI at which that directory is served. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.

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.

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.

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 (): 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.

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.

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

Remediation token issued after end user confirmation

The Retry The agent retries exactly the refused booking with the remediation token and a fresh DPoP proof:

Retry of the refused booking with the remediation token

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.

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.

Open Issues This appendix is non-normative; it records questions on which working group guidance is sought.

Stale Packaged Advertisements For native applications, 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 . 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 () is where the host container exchanges the agent's token for a web session credential (). 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.