> > Services that reject the defined multi value syntax make a choice to not > support multiple audiences, which is right by them. Waving a magic wand and > updating the syntax in a spec won't change that. > Having multiple syntaxes won't improve the interop situation and so I > don't see value in revisiting this. Same goes for multiple resource > indicators.
Certain services reject requests that contain multiple parameters with the same name, not because they intentionally prohibit such usage, but because their underlying server frameworks do not support multiple values for a single parameter by default. In these cases, supporting a single audience parameter that accepts multiple values would be more practical and interoperable. Additionally, including multiple parameters with the same name but different values directly contradicts RFC 6749, which explicitly states that request and response parameters *MUST NOT* be included more than once [1]. [1] https://datatracker.ietf.org/doc/html/rfc6749#section-3.2:~:text=unrecognized%20request%20parameters.-,Request%20and%20response%20parameters%0A%20%20%20MUST%20NOT%20be%20included%20more%20than%20once .,-3.2.1.%20%20Client%20Authentication On Sat, Feb 21, 2026 at 4:31 PM Filip Skokan <[email protected]> wrote: > Services that reject the defined multi value syntax make a choice to not > support multiple audiences, which is right by them. Waving a magic wand and > updating the syntax in a spec won't change that. > > Having multiple syntaxes won't improve the interop situation and so I > don't see value in revisiting this. Same goes for multiple resource > indicators. > > Turns out I've grown to like the fact it's using search params in the > intended way afterall. > > - Filip > > 21. 2. 2026 v 8:21, Thilakasiri H.A.B.D <[email protected]>: > > > 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] > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
