Should TEA 1.0 support RFC 8693 token exchange?

[Mehrn0ush]

Summary

/token documents RFC 8693 token exchange as an optional grant (urn:ietf:params:oauth:grant-type:token-exchange), but the request/response contract for it isn't fully specified in the OpenAPI schema.

This came up while working on #271/#272, which intentionally scope to RFC 6749 alignment for the mandatory client_credentials baseline (Pragma: no-cache, Basic client-auth encoding) and don't touch exchange. Before patching individual fields here, it's probably worth deciding whether TEA 1.0 actually intends to support token exchange, or defers it.

Current gaps

token-request only requires grant_type. subject_token and subject_token_type are plain optional properties — nothing ties them to being required when the exchange grant is actually used, so a request can satisfy the schema without the inputs RFC 8693 expects.
token-response has access_token, token_type, expires_in, and scope, but not issued_token_type, which RFC 8693 section 2.2.1 requires on a successful exchange response.
actor_token/actor_token_type aren't represented at all, so delegation-style exchanges (RFC 8693 section2.1) can't be expressed even informally.

Adding issued_token_type alone would patch the most visible gap but still leave the grant partially specified.

Decision needed

A — Support token exchange in 1.0. Spec the grant end-to-end: required/conditional request parameters, full response shape (including issued_token_type), and expected behavior for invalid or incomplete exchange requests.

B — Defer it past 1.0. Keep client_credentials + Bearer as the interoperable baseline, and either drop token exchange from the normative surface for now or explicitly mark it non-interoperable/deferred.

Shipping a half-specified profile risks different implementations interpreting it differently, which is worse than not shipping it yet.

My question

For 1.0, should RFC 8693 token exchange be part of the supported profile (A), or should we explicitly defer it (B)?

[taleodor]

I think we should go with B (mark non-interoperable / deferred) for 1.0.

[Mehrn0ush]

Sounds good — B matches what we’ve found so far: subject_token / subject_token_type aren’t constrained to the exchange grant, issued_token_type is missing from the response, and delegation params (actor_token) aren’t represented at all. Given that, and no known consumer yet, deferring seems like the safer call for 1.0.

Happy to be corrected if I'm missing something here.

• removes token exchange from the grant-type table and /token description in auth/readme.md
• notes that RFC 8693 is outside the TEA 1.0 interoperable profile (implementations may support it as an extension by separate agreement; clients shall not assume it from conformance alone)
• mirrors that in openapi.yaml, including removing unconstrained subject_token / subject_token_type
• keeps client_credentials as the required baseline