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 <t.bro...@gmail.com> 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"; <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
>> OAuth@ietf.org
>> 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
> 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._
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
