Defer RFC 8693 token exchange for TEA 1.0

auth/readme.md

@@ -172,9 +172,16 @@ nothing to them.
 |---|---|---|
 | Enterprise SSO where the customer's identity provider issues SAML assertions | `urn:ietf:params:oauth:grant-type:saml2-bearer` | [RFC 7522](https://www.rfc-editor.org/rfc/rfc7522) |
 | OpenID Connect, or any provider issuing signed JWTs, including workload identity in CI systems | `urn:ietf:params:oauth:grant-type:jwt-bearer` | [RFC 7523](https://www.rfc-editor.org/rfc/rfc7523) |
-| A client already holding a token from another security domain, exchanged for a TEA token | `urn:ietf:params:oauth:grant-type:token-exchange` | [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693) |
 | A client authenticated by a TLS client certificate rather than a shared secret | `client_credentials` with mutual TLS client authentication | [RFC 8705](https://www.rfc-editor.org/rfc/rfc8705) |
 
+[RFC 8693](https://www.rfc-editor.org/rfc/rfc8693) token exchange
+(`urn:ietf:params:oauth:grant-type:token-exchange`) is outside the scope of the TEA 1.0
+interoperable authentication profile. TEA 1.0 does not specify the request or response
+contract for this grant. Implementations __may__ support it as an extension by separate
+agreement, but clients __shall not__ assume its availability based solely on TEA 1.0
+conformance. Such extensions do not remove the requirement for servers requiring
+authentication to support the `client_credentials` baseline.
+
 [RFC 7521](https://www.rfc-editor.org/rfc/rfc7521) defines the common framework the two assertion
 grants share.
 
@@ -279,7 +286,7 @@ and it does not replace the challenge as the way a client discovers that authent
 * RFC 7521: Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants (https://www.rfc-editor.org/rfc/rfc7521)
 * RFC 7522: SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants (https://www.rfc-editor.org/rfc/rfc7522)
 * RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants (https://www.rfc-editor.org/rfc/rfc7523)
-* RFC 8693: OAuth 2.0 Token Exchange (https://www.rfc-editor.org/rfc/rfc8693)
+* RFC 8693: OAuth 2.0 Token Exchange (https://www.rfc-editor.org/rfc/rfc8693) — outside the TEA 1.0 interoperable authentication profile
 * RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (https://www.rfc-editor.org/rfc/rfc8705)
 * RFC 9068: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (https://www.rfc-editor.org/rfc/rfc9068)
 * RFC 9728: OAuth 2.0 Protected Resource Metadata (https://www.rfc-editor.org/rfc/rfc9728)

spec/openapi.yaml

@@ -726,10 +726,18 @@ paths:
         `404` from this endpoint means only that it is not implemented.
 
         Servers may support additional grant types for federated identity, for example
-        SAML 2.0 assertions (RFC 7522), JWT assertions (RFC 7523), or token exchange
-        (RFC 8693), and may authenticate the client with mutual TLS (RFC 8705) instead
-        of Basic. Whichever grant type is used, the token returned by this endpoint is
-        the only credential accepted on the other TEA endpoints.
+        SAML 2.0 assertions (RFC 7522) or JWT assertions (RFC 7523), and may authenticate
+        the client with mutual TLS (RFC 8705) instead of Basic. Whichever grant type is
+        used, the token returned by this endpoint is the only credential accepted on the
+        other TEA endpoints.
+
+        RFC 8693 token exchange (`urn:ietf:params:oauth:grant-type:token-exchange`) is
+        outside the scope of the TEA 1.0 interoperable authentication profile. TEA 1.0 does
+        not specify the request or response contract for this grant. Implementations may
+        support it as an extension by separate agreement, but clients shall not assume its
+        availability based solely on TEA 1.0 conformance. Such extensions do not remove the
+        requirement for servers requiring authentication to support the
+        `client_credentials` baseline.
 
         The access token is opaque to the client: clients shall not inspect, parse, or
         depend on its contents.
@@ -803,8 +811,10 @@ components:
     token-request:
       type: object
       description: |
-        Token request, as defined in RFC 6749 section 4.4.2 for the client-credentials
-        grant. Additional parameters apply only to the optional grant types.
+        Token request for the `client_credentials` grant, as defined in RFC 6749 section
+        4.4.2, or an optional assertion grant identified below. The `scope` parameter
+        applies to both. The `assertion` parameter applies only to assertion grants.
+        RFC 8693 token exchange is outside the TEA 1.0 profile (see `/token` description).
       required:
         - grant_type
       properties:
@@ -813,8 +823,9 @@ components:
           description: |
             OAuth 2.0 grant type. Servers shall support `client_credentials`. Servers may
             support assertion grants (`urn:ietf:params:oauth:grant-type:saml2-bearer`,
-            `urn:ietf:params:oauth:grant-type:jwt-bearer`) or token exchange
-            (`urn:ietf:params:oauth:grant-type:token-exchange`).
+            `urn:ietf:params:oauth:grant-type:jwt-bearer`). Token exchange
+            (`urn:ietf:params:oauth:grant-type:token-exchange`) is outside the TEA 1.0
+            interoperable authentication profile; see `/token`.
           example: client_credentials
         scope:
           type: string
@@ -824,12 +835,6 @@ components:
         assertion:
           type: string
           description: Assertion value, when an assertion grant type is used (RFC 7521 section 4.1).
-        subject_token:
-          type: string
-          description: Subject token, when the token-exchange grant type is used (RFC 8693 section 2.1).
-        subject_token_type:
-          type: string
-          description: Type of `subject_token`, when the token-exchange grant type is used (RFC 8693 section 2.1).
     token-response:
       type: object
       description: Successful token response, as defined in RFC 6749 section 5.1.