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]
