With the PR to OAuth 2.1 accepted I went ahead and opened RFC6749 erratas for both sections
- https://www.rfc-editor.org/errata/eid8790 - https://www.rfc-editor.org/errata/eid8791 S pozdravem, *Filip Skokan* On Mon, 23 Feb 2026 at 22:31, Brian Campbell <[email protected]> wrote: > Thanks Filip. > > I had forgotten about reporting that errata in 2019 and its > subsequent acceptance just five years later. Unfortunately, as you pointed > out, I also apparently forgot that there were two places in RFC 6749 where > the updated text was applicable - the last paragraph of both > https://datatracker.ietf.org/doc/html/rfc6749#section-3.1 and > https://datatracker.ietf.org/doc/html/rfc6749#section-3.2 > > For what it's worth, my thinking in using/allowing for multiple > occurrences of the 'audience' and 'resource' parameters in RFC 8693 and RFC > 8705 was: 1) wanting to avoid inventing yet another new delimiting and > escaping mechanism, and 2) reading the "MUST ignore unrecognized request > parameter" as taking precedence over the "MUST NOT be included more than > once." > > > > On Sun, Feb 22, 2026 at 3:28 AM Filip Skokan <[email protected]> wrote: > >> 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] >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
