Hi Group,

I am writing to raise a practical interoperability concern regarding the
handling of the 'audience' parameter in RFC 8693 (OAuth 2.0 Token
Exchange), specifically in cases where multiple audience values need to be
specified in a single token exchange request.

*The Current Situation*

RFC 8693 states that the 'audience' parameter may be included multiple
times to indicate multiple target audiences:

  *"The 'audience' request parameter may be repeated to indicate multiple
target services."*

However, RFC 6749  states:

  *"Parameters MUST NOT be included more than once."*

This creates a direct contradiction that causes real world interoperability
failures.

*The Problem in Practice*

Many production OAuth server implementations and HTTP frameworks strictly
enforce the RFC 6749 restriction and reject requests with repeated
parameter names before they even reach grant handler logic. This includes:

When a client sends:

  audience=serviceA&audience=serviceB

Many servers respond with:

  { "error": "invalid_request", "error_description": "Invalid request with
repeated parameters." }

...before the token exchange logic is ever reached, making the feature
entirely unusable in those environments.

*Proposed Clarification*

We would like to propose that RFC 8693 be updated or clarified to
explicitly recommend a delimiter-separated single parameter as the primary
mechanism for specifying multiple audience values. For example:

  audience=serviceA,serviceB,serviceC

or space-separated, consistent with the 'scope' parameter convention in RFC
6749:

  audience=serviceA%20serviceB%20serviceC

Implementations could then note that repeated parameter support is OPTIONAL
and only permitted where the underlying framework allows it.This would
align RFC 8693 with real-world deployment constraints without breaking
existing implementations that do support repeated parameters.
We would appreciate the group's thoughts on this and welcome discussion on
the most appropriate path forward.

Thank you for your time and consideration.

Best regards
H.A.B.D Thilakasiri
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to