From 305c3f95727c9ece711cacbba04c86b3425272a5 Mon Sep 17 00:00:00 2001 From: Mehrn0ush Date: Mon, 14 Sep 2026 15:41:54 +0800 Subject: [PATCH] Defer RFC 8693 token exchange for TEA 1.0 Mark token exchange as outside the interoperable profile and remove the incomplete subject_token fields. Keeps the client_credentials baseline from #258, and narrows its token-exchange mention to an optional future extension pending a concrete consumer. Closes #273. Signed-off-by: Mehrn0ush --- auth/readme.md | 11 +++++++++-- spec/openapi.yaml | 33 +++++++++++++++++++-------------- 2 files changed, 28 insertions(+), 16 deletions(-) diff --git a/auth/readme.md b/auth/readme.md index 30b49ac..8767179 100644 --- a/auth/readme.md +++ b/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) diff --git a/spec/openapi.yaml b/spec/openapi.yaml index 758804f..a551724 100644 --- a/spec/openapi.yaml +++ b/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.