Errata 5708 has been reported attempting to clarify the situation.
https://www.rfc-editor.org/errata/eid5708
On Mon, Apr 22, 2019 at 9:53 AM Thomas Broyer wrote:
> 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 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 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 <
>>> vladi...@connect2id.com> 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; ,
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> --
>>> Thomas Broyer
>>> /tɔ.ma.bʁwa.je/
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> 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.*
>
>
--
_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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
