Subject: [OAUTH-WG] How to deal with multi-valued request parameters in a JAR (draft-ietf-oauth-jwsreq-17)?

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 22 Apr 2019 11:15:27 +0300

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

---

From: Brian Campbell <[email-masked]>
Date: Mon, 22 Apr 2019 05:42:42 -0600

FWIW, the second paragraph of resource indicators, section 2.1
<https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#section-2.1>
says to use a JSON array via the following text:

   For authorization requests sent as a JWTs, such as when using JWT
   Secured Authorization Request [I-D.ietf-oauth-jwsreq
<https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#ref-I-D.ietf-oauth-jwsreq>],
a single
   "resource" parameter value is represented as a JSON string while
   multiple values are represented as an array of strings.

On Mon, Apr 22, 2019 at 2:15 AM Vladimir Dzhuvinov <[email-masked]>
wrote:

> 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>,
>       "redirect_uri": "https://client.example.org/cb" <https://client.example.org/cb>,
>       "scope": "openid",
>       "state": "af0ifjsldkj",
> Apart from custom params, the resource indicators spec also suggests that
> such situations can occur:
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> 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._

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 22 Apr 2019 15:52:17 +0200

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.

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 22 Apr 2019 09:38:38 -0600

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-masked]> wrote:

> 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
> resource indicators) or unrecognized (and therefore ignored) parameters..
>
> On Mon, Apr 22, 2019 at 10:15 AM Vladimir Dzhuvinov <
> [email-masked]> wrote:
>

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 22 Apr 2019 17:53:14 +0200

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-masked]> 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
>>  * multi-valued request params shouldn't exist ("scope" is a single
>> string value with a specific format, as a space-separated list of scopes)
> *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.*

---

From: Brian Campbell <[email-masked]>
Date: Mon, 29 Apr 2019 06:34:10 -0600

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 <[email-masked]> wrote:

> 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)
>
>