An errata <https://www.rfc-editor.org/errata/eid5708> for this was reported in 2019 and accepted in 2024. Unfortunately that errata only touches the authorization endpoint, not the token endpoint. The errata language is however present for both endpoints in OAuth 2.1 <https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-14.html>.
I have opened a PR <https://github.com/oauth-wg/oauth-v2-1/pull/238> further clarifying this language (i think so at least) in 2.1 to make it clear that prohibited is the default behaviour for all extension parameters but leave room for parameters in which this is explicitly defined. This should close the door for an interpretation in which all extension parameters can be sent multiple times with undefined behaviour. Bottom line the intention and consensus (based on the accepted errata and 2.1 language) is that parameters must not be repeated unless a parameter is defined such that it allows it to be sent multiple times. If accepted in 2.1 I think we should send that errata to 6749 for the authorization endpoint (again) and the token endpoint. S pozdravem, *Filip Skokan* On Sun, 22 Feb 2026 at 10:24, Warren Parad <[email protected]> wrote: > Normally this would seem fine, bpt I completely disagree with this. > > When designing an API that round-trips ownership control over the > parameters interpretation. It doesn't matter the format/style/explode type. > > However, this is not one of those times. The audience parameter as well as > others are going to be used in interop scenarios with clients that won't be > able to a priori know how a particular API will Interpret a parameter. > > This will lead to cases where an OAuth API might start to receive a comma > delimited list because while even though it doesn't know what to do with > it, other services might have conveyed that is the right way to send > multiple values. > > This would cause the audience parameter to immediately break for all those > APIs where a comma delimited list is not expected, because that parameter > value will be treated as a single audience, and would almost for sure be > interpreted incorrectly by RS everywhere. > > The only acceptable solution would be to allow the audience parameter to > be specified multiple times in the URL. That way APIs that do not support > it, can gracefully pull out the first one (or last one, or break in > confusing ways due to the particularly of the framework they are usingo, > but at least returning 500 provides a consistent experience). And everyone > else can handle the repeated parameter correctly as desired. > > The reason this is better, is because APs must already have a validation > in place to prevent duplicate query parameters, or be implicitly handling > it consistently correctly, or degrading successfully. No such option would > be available for a comma delimited list as there is no guarantee that every > OAuth API is already blocking the use of commas in the query string > parameters today. > > On Sun, Feb 22, 2026, 02:39 Pavindu Lakshan <[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. >> >> 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] >> >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
