]> Independent

public@karlmcguinness.com

Okta

aaron@parecki.com https://aaronparecki.com

Security Web Authorization Protocol OAuth 2.0 Token Exchange Identity Chaining Resource Indicators Cross-Domain Authorization This specification defines a method for OAuth 2.0 clients to discover the set of available Token Exchange Targets (such as audiences, resources, scopes, and token types) for a given subject token when performing OAuth 2.0 Token Exchange. The discovery endpoint accepts a subject token of any type the authorization server supports, identified by a token type URI, and returns values that are valid inputs to subsequent Token Exchange requests, supporting advanced use cases such as identity chaining and cross-domain delegation. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction OAuth 2.0 Token Exchange enables a client to present a token issued in one security domain to an authorization server and securely trade it for a new token issued for another domain. The exchanged token is minted with the Target Service's token requirements, including its own audience, resource indicators, and scopes, so it becomes valid and enforceable for the desired downstream service. This enables controlled cross-domain access, removes the confused-deputy problem by ensuring tokens are explicitly targeted to the correct service, and avoids requiring direct trust between the original token issuer and the Target Service. Authorization Servers may be capable of issuing tokens to multiple services for a given subject token and client, but the client must already know which values it may request. Today, this knowledge is typically provided through static configuration, proprietary APIs, or informal documentation, leading to brittle integrations and unnecessary Token Exchange failures, particularly when subjects are authorized to access only a subset of available services. This specification defines the OAuth 2.0 Token Exchange Target Service Discovery Endpoint, a standardized mechanism that enables clients to dynamically discover the set of available Token Exchange Targets (such as audiences, resources, scopes, and token types) for a given subject token. The authorization server evaluates both the subject token and the client's permissions and returns only the values the client is authorized to request. This extension is especially valuable in scenarios requiring identity chaining and cross-domain authorization:

• Progressive token exchange across service boundaries, such as multi-tier microservices architectures and delegated flows where tokens are exchanged with narrower or transformed permissions at each hop. The set of downstream services a client may target, and their required permissions, varies with the subject token's context and the client's authorization, so static configuration cannot anticipate these per-subject and per-client variations and clients attempt exchanges the subject is not authorized to perform.
• Cross-boundary deployments where downstream services exist in separate administrative, organizational, or cloud domains with independently managed authorization policies. Unlike progressive token exchange, which transforms permissions within a single domain, this scenario spans distinct trust boundaries whose policies and authorized targets change dynamically, so a client must discover them at runtime rather than rely on fixed configuration.
• Single Sign-On (SSO) to API flows, such as those enabled by the Identity Assertion Authorization Grant (ID-JAG) , where a client needs to seamlessly connect to cross-domain resources and act on behalf of the user to access APIs.
• Multi-tenant Target Services that share the same authorization server and/or resource across tenants, where the tenant is identified by a claim in the issued token. In these scenarios, the resource indicator alone cannot distinguish the tenants, so discovery enables a client to learn the distinct Target Services available per tenant and to present a tenant selection to the end user.

This specification provides the following benefits:

• Dynamic Discovery: Eliminates static configuration requirements by enabling clients to discover available Token Exchange Targets at runtime, reducing integration failures and improving developer experience.
• Standardization: Provides a standardized discovery mechanism, replacing proprietary APIs and improving interoperability across OAuth 2.0 implementations.
• Real-Time Authorization: Returns Token Exchange Targets based on real-time policy evaluation, client permissions, and subject token context, ensuring accurate and up-to-date authorization information. This enables per-subject and per-client results, which is essential when the set of available targets varies by user or client.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the following terms:

Target Service

A downstream service that a client accesses using a token obtained through OAuth 2.0 Token Exchange . A Target Service may be multi-tenant (see ).

Token Exchange Target

A combination of Token Exchange request parameters (an audience and, where applicable, resource, scope, and requested token type(s)) that the authorization server has authorized for a given subject token and requesting client. A Token Exchange Target is returned by the discovery endpoint as an element of the supported_targets array; it identifies how a client may obtain a token for a Target Service and does not assert that the service is reachable or operational.

Token Exchange Target Service Discovery Endpoint This specification defines a new endpoint for OAuth 2.0 authorization servers that enables clients to discover the set of available Token Exchange Targets (such as audiences, resources, scopes, and token types) for a given subject token when performing OAuth 2.0 Token Exchange . The endpoint is identified by the authorization server metadata parameter token_exchange_target_service_discovery_endpoint, as defined in .

Authorization Server Metadata This specification defines the following authorization server metadata parameter to enable clients to discover the token exchange target service discovery endpoint:

token_exchange_target_service_discovery_endpoint

URL of the token exchange target service discovery endpoint. This URL MUST use the https scheme. The authorization server SHOULD publish this metadata value.

The following is a non-normative example of the metadata:

Endpoint Request The client makes a request to the token exchange target service discovery endpoint by sending an HTTP POST request to the endpoint URL. The client MUST use TLS as specified in . The endpoint URL MUST be obtained from the authorization server's metadata document using the token_exchange_target_service_discovery_endpoint parameter. The endpoint URL is an absolute URL. The client sends the parameters using the application/x-www-form-urlencoded format per Appendix B of . Character encoding MUST be UTF-8 as specified in Appendix B of . If a parameter is included more than once in the request, the authorization server MUST return an error response with the error code invalid_request as described in .

Request Parameters The following parameters are used in the request:

subject_token

REQUIRED. The subject token used as input to discovery. The token type is indicated by the subject_token_type parameter.

subject_token_type

REQUIRED. A string value containing a URI, as described in , that indicates the type of the subject_token parameter. This identifier MUST be a valid URI, and SHOULD be registered in the "OAuth URI Registry" as established by .

The client MAY include additional parameters as defined by extensions, and the authorization server MUST ignore parameters it does not understand. The parameters of the client authentication method in use (for example, client_id, client_secret, or client_assertion and client_assertion_type) are part of that method and are not treated as unknown parameters. The authorization server identifies the requesting client in order to evaluate its permissions (). Client authentication MAY be required by the authorization server. The means of client authentication are defined by the authorization server and MAY include any method supported by the authorization server, including those defined in and extensions. If client authentication is required by the authorization server but not provided in the request, the authorization server MUST return an error response with the error code invalid_client as described in . A public client that does not authenticate MAY identify itself with the client_id parameter; the authorization server determines the trust it places in such an unauthenticated identifier, and MAY base its results on the subject token alone when no client identity is established.

Subject Token Processing The authorization server MUST process the subject_token parameter according to the following rules:

1. The authorization server MUST validate that the subject_token and subject_token_type parameters are not empty strings. If either parameter is an empty string, the authorization server MUST return an error response with the error code invalid_request as described in .
2. The authorization server MUST validate that the subject_token_type parameter is a valid URI. If the format is invalid (e.g., not a valid absolute URI or URN), the authorization server MUST return an error response with the error code invalid_request as described in .
3. The authorization server MUST determine whether it supports the indicated token type. This determination is an implementation decision and MAY be based on the authorization server's capabilities, the subject_token value, the authenticated client, or any combination thereof. If the subject_token_type is not supported by the authorization server for the given context, the authorization server MUST return an error response with the error code unsupported_token_type as described in .
4. The authorization server MUST validate the subject_token according to the rules for the indicated token type. The validation process MUST verify:
   • The token is properly formatted for the indicated token type
   • The token's signature (if applicable) is valid and can be verified using the appropriate cryptographic keys
   • The token was issued by a trusted issuer
   • The token has not expired
   • The token has not been revoked, where revocation status is applicable and available for the token type; a token known to be revoked MUST be rejected
   • The token is associated with the authenticated client, if client authentication is required
5. If the subject_token is invalid for any reason (e.g., malformed, expired, revoked, or does not match the subject_token_type), the authorization server MUST return an error response with the error code invalid_request as described in .
6. The authorization server MUST evaluate the subject_token in conjunction with the requesting client's permissions (the authenticated client, when client authentication is used) to determine which Token Exchange Targets are available for discovery. The specific authorization policy evaluation mechanism is implementation-specific and MAY be based on scopes, claims, resource-based access control, or other authorization models.

Request Example The following is an example of a discovery request:

Endpoint Response The authorization server validates the request and returns a response with the discovery results. The Content-Type header of the response MUST be set to application/json. Because the response contains sensitive, per-subject and per-client authorization information, the authorization server SHOULD set Cache-Control: no-store by default. A deployment that accepts the associated risk MAY instead permit bounded private caching; in that case the cache directives MUST mark the response as private (for example, Cache-Control: private) and shared caches MUST NOT store it. The authorization server MAY include cache validators (such as ETag or Last-Modified headers) to enable conditional requests by the client, as specified in .

Successful Response If the request is valid and authorized, the authorization server returns a JSON object containing a supported_targets property: an array of the Token Exchange Targets (see ) available to the client. To perform a token exchange, the client selects one target and uses its values as the corresponding request parameters. Empty and null values are not valid property values. The authorization server MUST NOT include an optional property whose value would be null, an empty string, an empty array, or an array containing an empty string; it MUST omit the property instead. A REQUIRED property MUST have a non-empty value. Each target object contains the following properties:

audience

REQUIRED. The value the client uses, verbatim, as the audience parameter in a subsequent token exchange request, identifying the Target Service as defined in . Its syntax is authorization-server-defined unless constrained by a profile of this specification; the client MUST treat it as opaque and MUST NOT assume it is a URI. If the value is a URI that does not itself provide a usable location (for example, a URN), the authorization server SHOULD also return a resource property that provides one. A multi-tenant Target Service returns a distinct audience value per tenant; see .

tenant

OPTIONAL. A machine-readable identifier for the tenant of a multi-tenant Target Service. The issued token represents this tenant using the claim defined by the token format and Target Service (for example, the aud_tenant claim when the Identity Assertion Authorization Grant is used); the specific claim name and encoding are outside the scope of this specification. This property is included only when the Target Service is multi-tenant and the authorization server knows the tenant identifier. It is descriptive: it lets the client correlate a Target Service with the tenant context of the resulting issued token, and is not used as a selector in the token exchange request (the audience value selects the tenant).

resource

OPTIONAL. A single resource indicator value or an array of resource indicator values, as defined in , available for this target. Each value MUST be an absolute URI and MUST NOT include a fragment component, per . If present as an array, the array entries correspond to repeated resource parameters in the subsequent token exchange request.

scope

OPTIONAL. A string value containing a space-delimited list of OAuth 2.0 scope values, as defined in , that are available for this target. Each scope value MUST conform to the scope syntax defined in . If present, the value MUST contain at least one scope value. The authorization server determines which scopes to return based on its authorization policy evaluation, which is implementation-specific. The scopes returned SHOULD be those that would be authorized in a subsequent token exchange request per .

supported_token_types

OPTIONAL. An array of strings indicating the token types that may be requested for this target in a subsequent token exchange operation. Each string MUST be a valid absolute URI. A token type identifier MAY be any URI, as permitted by , when that URI identifies the requested token type or token usage profile understood by the authorization server and client. For example, urn:ietf:params:oauth:grant-type:jwt-bearer identifies a JWT intended to be presented as a JWT bearer authorization grant as defined by ; this specification intentionally permits the RFC 7523 grant-type URI to be used in this role, which the generic urn:ietf:params:oauth:token-type:jwt identifier does not convey. If omitted, the client may use any token type supported by the authorization server.

display_name

OPTIONAL. A human-readable name for the Target Service, suitable for display to an end user (for example, in a service picker). This value is intended for presentation only and MUST NOT be used as a token exchange parameter.

client_id

OPTIONAL. The OAuth 2.0 client identifier that the client uses with the Target Service when presenting the issued token (see ). This property supports multi-tenant Target Services that require a distinct client registration for each tenant. The client is expected to possess credentials for the indicated client identifier where client authentication applies. If omitted, the client uses a client identity it determines is appropriate by other means.

Extensions to this specification MAY define additional properties for the response object or for target objects. Clients MUST ignore any properties they do not understand. A target is identified by its audience together with its resource set (the complete set of resource values, or their absence). This key MUST be unique within the supported_targets array: no two targets may share both the same audience and the same resource set (when comparing sets, element order does not matter, but the membership must match). Multiple targets with the same audience MAY therefore be returned only when they differ in their resource set. Because each key appears at most once, a target's scope is the aggregate set of scopes authorized for that key, rather than one of several alternative scope bundles. A multi-tenant Target Service is represented as one target per tenant, each with a distinct audience (see ), so the audience distinguishes the tenants. If no Token Exchange Targets are available for the given subject token and client, the authorization server returns a JSON object with an empty supported_targets array: {"supported_targets": []}. Discovery results reflect authorization at the time of the request and are not a guarantee. The authorization server re-evaluates authorization when the subsequent token exchange is performed, and that exchange might still fail (for example, if policy changed, the subject token expired, or the target became unavailable in the interim). A client MUST handle errors from the token exchange request rather than assuming a discovered target will succeed.

Response Example The following is an example of a successful discovery response:

Multi-Tenant Target Services A Target Service may be multi-tenant, sharing the same authorization server and/or the same resource across two or more tenants, where the tenant is identified by a claim in the issued token. For example, an authorization server as.saas.example may host two tenants, dev and staging, that share the resource https://api.saas.example. Because the resource (and authorization server) is shared, the resource indicator alone cannot distinguish the tenants. To support this case without changing the OAuth 2.0 Token Exchange request contract, the authorization server represents each tenant of a multi-tenant Target Service as a separate target object with a distinct audience value. As described for the audience property, the client uses the discovered value verbatim as the audience parameter in the subsequent token exchange request, and the authorization server resolves it to the tenant-specific audience and tenant context in the issued token. The claim that conveys the tenant in the issued token is determined by the token format and Target Service (for example, the aud_tenant claim when the Identity Assertion Authorization Grant is used) and is outside the scope of this specification. When a Target Service is multi-tenant, the authorization server SHOULD include the tenant property so that the client can correlate the Target Service with the tenant context of the resulting issued token, and SHOULD include the display_name property so that a client can present a tenant picker to an end user. If a multi-tenant Target Service requires a distinct client registration for each tenant, the authorization server MAY include the client_id property in each target object to indicate the client identifier the client uses with that tenant when presenting the issued token. The issued token is not necessarily presented through token exchange: depending on the Target Service, it may be an authorization grant, such as an ID-JAG , that the client redeems at the Target Service's authorization server (where this client_id is used for client authentication), or an access token that the client presents directly to a resource server. If a shared client registration is used across tenants, the client_id property is omitted. The following is a non-normative example of a discovery response for a multi-tenant Target Service with two tenants that share the same resource: The client presents the two tenants to the end user using the display_name values (for example, "SaaS Example Dev" and "SaaS Example Staging"). Once the user selects a tenant, the client performs the token exchange using the corresponding audience value (for example, urn:saas:tenant:dev). When the resulting issued token is later presented at the Target Service, the client uses the corresponding client_id, if present and where client authentication applies.

Error Response If the request failed, the authorization server returns an error response as defined in . The response MUST use the application/json media type, and the Content-Type header MUST be set to application/json. In addition to the error codes specified in , the following error codes may be returned:

unsupported_token_type

The authorization server does not support the subject token type indicated by the subject_token_type parameter.

The HTTP status code is determined as specified in . In particular, when the error is invalid_client and the client attempted to authenticate via the Authorization request header field, the authorization server responds with HTTP 401 (Unauthorized) and includes a WWW-Authenticate response header field; otherwise it responds with HTTP 400 (Bad Request). When the authorization server rate-limits a client (see ), it MAY respond with HTTP 429 (Too Many Requests) and SHOULD include a Retry-After header field .

Error Response Example The following is an example of an error response:

Example This example demonstrates a complete cross-domain identity chaining workflow described in with the addition of the token exchange target service discovery endpoint.

Step 1: Discover Target Services The client begins with a subject access token issued by Domain A and calls the target service discovery endpoint to learn which Token Exchange Targets are available.

Discovery Request

Discovery Response From this response, the client learns that it may request a token exchange for the audience https://api.domainB.example with the resources https://api.domainB.example/orders and https://api.domainB.example/inventory and the scopes orders.read and inventory.read. The supported_token_types value tells the client that, in the subsequent token exchange, it may request a JWT to be presented to the Target Service as a jwt-bearer authorization grant .

Step 2: Determine Token Types (Optional) The discovery response's supported_token_types property indicates the token types the client may request for the target. In this example it listed urn:ietf:params:oauth:grant-type:jwt-bearer, so the client proceeds directly to the token exchange. When a discovery response omits supported_token_types, the client determines the requestable token types from the Target Service's documentation or other out-of-band configuration.

Step 3: Perform Token Exchange The client now performs a token exchange with Domain A's token endpoint, requesting a JWT for Domain B using the values discovered in the previous steps.

Token Exchange Request

Token Exchange Response The client now holds a Domain-B-scoped JWT token that can be used to access the Target Service, derived from Domain A's access token through the token exchange process.

Security Considerations

Subject Token Validation The authorization server MUST validate the subject token as specified in . In particular, it MUST verify that the token is well-formed for the indicated type, is correctly signed by a trusted issuer, has not expired, has not been revoked (where revocation status is applicable and available), and, where client authentication is required, is associated with the authenticated client. A token that fails validation MUST be rejected as described in .

Client Authentication The authorization server SHOULD require client authentication for the discovery endpoint to prevent unauthorized access to authorization information. The authorization server MUST support at least one of the client authentication methods defined in . If client authentication is required but not provided, the authorization server MUST return an error response with the error code invalid_client as described in .

Authorization Policy Enforcement The authorization server MUST evaluate both the subject token and the client's permissions when determining which Token Exchange Targets to return. The server MUST only return targets that the client is authorized to request in a subsequent token exchange operation. The specific authorization policy evaluation mechanism is implementation-specific and MAY be based on scopes, claims, resource-based access control, attribute-based access control, or other authorization models supported by the authorization server.

Information Disclosure The discovery endpoint reveals information about which Target Services are available for a given subject token and client. This information could be used by an attacker to enumerate authorization relationships. To mitigate this risk:

• The authorization server SHOULD require client authentication
• The authorization server SHOULD apply rate limiting to prevent enumeration attacks
• The authorization server MAY return different results based on the authenticated client to limit information disclosure
• The authorization server SHOULD log access to the discovery endpoint for security monitoring

Multi-Tenant Information Disclosure For multi-tenant Target Services, the tenant, display_name, and client_id properties reveal the existence of specific tenants and, where present, the per-tenant client registration topology of the authorization server. This information could be used by an attacker to enumerate tenants or client registrations. The authorization server MUST only return target objects, including their tenant and client registration properties, that the authenticated client is authorized to discover, applying the same authorization policy enforcement and information disclosure mitigations described in this section. The authorization server SHOULD NOT include a client_id value that the authenticated client is not authorized to use.

Token Confidentiality The subject token is transmitted in the request. The authorization server MUST require the use of TLS as specified in to protect the token in transit. Because the request body carries a live credential, the authorization server MUST NOT record the subject_token (or other equally sensitive request content) in logs, audit records, or error reports, and SHOULD avoid emitting it where it could be retained by intermediaries.

Error Handling The authorization server MUST NOT provide detailed error messages that could aid an attacker in understanding the authorization server's internal state or policies. Error responses SHOULD be generic and not reveal specific information about why a request failed beyond what is necessary for the client to correct the request.

Privacy Considerations The discovery endpoint returns information about authorization relationships between subjects, clients, and Target Services. This information may be considered privacy-sensitive, as it reveals:

• Which Target Services a subject is authorized to access
• The scope of permissions available for each Target Service
• The existence of authorization relationships
• For multi-tenant Target Services, the specific tenants a subject is associated with or authorized to access, as conveyed by the tenant, display_name, and client_id properties

To protect privacy:

• The authorization server SHOULD only return information that the authenticated client is authorized to know
• The authorization server SHOULD apply the principle of least privilege when determining which Token Exchange Targets to return
• The authorization server SHOULD only disclose tenant-identifying properties (tenant, display_name, and client_id) for the tenants that both the subject and the authenticated client are authorized to access
• The authorization server SHOULD log access to the discovery endpoint in accordance with applicable privacy regulations
• The authorization server MAY provide mechanisms for subjects to control or limit the information returned by the discovery endpoint

IANA Considerations

OAuth Authorization Server Metadata Registry This specification registers the following value in the IANA "OAuth Authorization Server Metadata" registry established by . Metadata Name: token_exchange_target_service_discovery_endpoint Metadata Description: URL of the token exchange target service discovery endpoint Change Controller: IETF Specification Document(s): [[ This document ]]

OAuth Extensions Error Registry This specification registers the following error in the IANA "OAuth Extensions Error Registry" established by , adding a usage location for the token exchange target service discovery endpoint. The error name unsupported_token_type is also registered for other usage locations (for example, the token revocation endpoint); this registration adds a distinct usage location and does not change the existing entries. Error Name: unsupported_token_type Error Usage Location: Token exchange target service discovery endpoint response Related Protocol Extension: OAuth 2.0 Token Exchange Target Service Discovery Change Controller: IETF Specification Document(s): [[ This document ]]

References Normative References 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] This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. 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. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. 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. Informative References This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK] This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications. This document is not an Internet Standards Track specification; it is published for informational purposes. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed.

Acknowledgments The authors would like to thank the following individuals who contributed ideas, feedback, and wording that helped shape this specification: Max Gerber

Document History -02

• Added optional support for multi-tenant Target Services that share an authorization server and/or resource across tenants, via the optional tenant, display_name, and client_id properties and a new Multi-Tenant Target Services section; a distinct audience per tenant selects the tenant without changing the OAuth 2.0 Token Exchange request contract.
• Added a terminology section defining "Target Service" (the downstream service) and "Token Exchange Target" (a pre-authorized combination of Token Exchange request parameters); named each response element a "target object"; and clarified that discovery returns authorized Token Exchange Targets, not an assertion that a service is reachable.
• Defined the audience property as the exact, opaque value the client uses verbatim in Token Exchange, with authorization-server-defined syntax unless profiled, and specified that the (audience, resource set) pair uniquely identifies a target whose scope is the aggregate authorized for that pair.
• Clarified requesting a JWT for use as an RFC 7523 jwt-bearer authorization grant: examples and supported_token_types use urn:ietf:params:oauth:grant-type:jwt-bearer as the token type value (replacing the invalid urn:ietf:params:oauth:token-type:jwt-bearer), a token type identifier must identify the requested token type or usage, and RFC 7523 is now normative.
• Aligned the resource property with RFC 8707 (absolute URI, no fragment, array entries mapping to repeated resource parameters).
• Consolidated empty-value handling into a single rule: optional properties with an empty string, empty array, or null value are omitted, and a present scope contains at least one value.
• Clarified the client identity model (client authentication parameters are not unknown parameters; public-client identification) and that the requesting client's permissions are evaluated.
• Switched the caching reference to RFC 9111 (normative): no-store by default, with bounded private caching as an opt-in and no shared-cache storage.
• Defined error behavior: registered an unsupported_token_type usage location in the OAuth Extensions Error Registry, mapped invalid_client to HTTP 401 per RFC 6749, and added HTTP 429 with Retry-After (RFC 6585, RFC 9110) for rate limiting.
• Strengthened security and privacy guidance: the subject token must not be logged, the subject-token revocation check applies where revocation status is available, and multi-tenant tenant/client information is disclosed only to authorized clients.
• Moved the Authorization Server Metadata parameter into the endpoint section so the endpoint URL is discovered before it is used.
• Editorial: replaced the obsolete RFC 7159 reference with RFC 8259, corrected the abbrev value, set IANA change controllers to IETF, added client authentication to the examples, narrowed the abstract, and made terminology and capitalization consistent.

-01

• Changed discovery response to an object for extensibility with supported_targets param
• Updated references

-00

• Initial revision