And the root issue is that it *is* subject to interpretation. Parameters sent without a value MUST be treated as if they were omitted from the request. The authorization server MUST ignore unrecognized request parameters. Request and response parameters MUST NOT be included more than once.
The first sentence clearly applies to all parameters, whether recognized or not. It's unfortunately not clear to what the third applies, but BECAUSE it can be understood as applying to unrecognized parameters as well, I think it SHOULD be interpreted that way (until an errata clarifies the situation) Le lun. 22 avr. 2019 17:39, Brian Campbell <[email protected]> a écrit : > My interpretation of RFC6749's “Request and response parameters MUST NOT > be included more than once" is that it is applicable only to the parameters > defined therein. Which (conveniently but defensibly) allows for extensions > like resource indicators and token exchange to have multiple instances of a > parameter value without having to invent some new scheme to encode or > delimit multiple values. > > On Mon, Apr 22, 2019 at 7:52 AM Thomas Broyer <[email protected]> wrote: > >> RFC6749 makes it clear that “Request and response parameters MUST NOT be >> included more than once.” >> So: >> * multi-valued request params shouldn't exist ("scope" is a single >> string value with a specific format, as a space-separated list of scopes) >> * resource indicators draft violates RFC6749 by explicitly allowing >> multiple "resource" params; and RFC6749-compliant server is free to reject >> such a request with an invalid_request error, meaning that resource >> indicators breaks interoperability (clients can only send multi resource >> params to servers they know won't reject them with invalid_request as >> they're allowed to by RC6749). >> One could interpret that stance in RFC6749 as applying only to those >> params defined in this spec, but it's not explicitly said, so it could be >> interpreted as applying to any parameter, including extensions (like >> resource indicators) or unrecognized (and therefore ignored) parameters... >> >> On Mon, Apr 22, 2019 at 10:15 AM Vladimir Dzhuvinov < >> [email protected]> wrote: >> >>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-4 >>> >>> How should multi-valued request params be expressed in the JWT claims >>> set? As values in a JSON array? >>> >>> { >>> "iss": "s6BhdRkqt3", >>> "aud": "https://server.example.com"; <https://server.example.com>, >>> "response_type": "code id_token", >>> "client_id": "s6BhdRkqt3", >>> "redirect_uri": "https://client.example.org/cb"; >>> <https://client.example.org/cb>, >>> "scope": "openid", >>> "state": "af0ifjsldkj", >>> "some-query-param": [ "val-1", "val-2" ] >>> } >>> >>> Apart from custom params, the resource indicators spec also suggests >>> that such situations can occur: >>> >>> >>> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#section-2 >>> >>> Thanks, >>> >>> Vladimir >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> -- >> Thomas Broyer >> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > > *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] https://www.ietf.org/mailman/listinfo/oauth
