I’m not sure a delimited format will work, as the syntax of the audience parameter is not defined. So anything you pick as a delimiter is potentially ambiguous.
> On 21 Feb 2026, at 07:21, Thilakasiri H.A.B.D <[email protected]> > wrote: > > > 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]
