Re: [OAUTH-WG] [JAR] scope parameter outside request object of OIDC request

Vladimir Dzhuvinov <vladimir@connect2id.com> Thu, 24 September 2020 10:14 UTC

Return-Path: <vladimir@connect2id.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777923A005E for <oauth@ietfa.amsl.com>; Thu, 24 Sep 2020 03:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.896
X-Spam-Level:
X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OyiHK3nWPVf for <oauth@ietfa.amsl.com>; Thu, 24 Sep 2020 03:14:11 -0700 (PDT)
Received: from p3plsmtpa06-05.prod.phx3.secureserver.net (p3plsmtpa06-05.prod.phx3.secureserver.net [173.201.192.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B583A005C for <oauth@ietf.org>; Thu, 24 Sep 2020 03:14:11 -0700 (PDT)
Received: from [10.7.155.152] ([90.75.246.51]) by :SMTPAUTH: with ESMTPSA id LOGPkoZ19v1NGLOGQkBFc3; Thu, 24 Sep 2020 03:14:11 -0700
X-CMAE-Analysis: v=2.3 cv=AbLP4EfG c=1 sm=1 tr=0 a=dqIGGK8WkwP9YsiiukqjPw==:117 a=dqIGGK8WkwP9YsiiukqjPw==:17 a=9cW_t1CCXrUA:10 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=PfRflgRA0iZ7y315k_QA:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=Z2OJ7WRTBcLPi0BLUIMA:9 a=c62jOLRsS3U4UuOi:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
Cc: oauth <oauth@ietf.org>
References: <CAHdPCmOPwqbemgKsEALA0OvP+6z58N5eNA9WA_AsvDESNhE1kg@mail.gmail.com> <2cd8bfd1-f491-0086-979f-0527ccf16281@connect2id.com> <CAHdPCmPmABt6PyupuGZaofwp+jKy7aVEvUO488NdDzVFsD18BA@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <e13b2c81-8b8f-636d-7793-a4ab84dda66f@connect2id.com>
Date: Thu, 24 Sep 2020 13:14:08 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAHdPCmPmABt6PyupuGZaofwp+jKy7aVEvUO488NdDzVFsD18BA@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020508020701080807080901"
X-CMAE-Envelope: MS4wfArH2AHgYz4sC64rNekh6vKgFxfFixRbBxOoOvtwlXlA/4k4/P1wfX3PvYrjUNBemGkWpOfQRALMpbUEul1nGw+IpUu04tJMJ97ItoK8beHhvD8qMlan LePPEjQLtbFfy8nwNQmjorobcr84A56m9w29q7qjvxnkRNGpMG5qn6uS
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/x2zKJ3rGXDLb_wAhv3fX57NWakU>
Subject: Re: [OAUTH-WG] [JAR] scope parameter outside request object of OIDC request
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2020 10:14:13 -0000

Hi Taka,

Speaking of the OIDC Core 1.0 conformance tests, IMO those should not
change with the publication of JAR.

Speaking of the FAPI 1.0 tests, those already require all request
parameters to be JWT-secured, which makes the requests also JAR
compliant: all parameters are found in the JWT, with scope (as complete
scope or minimally required scope=openid), response_type, client_id and
redirect_uri also having a copy outside the JWT, as query parameters.
Thus the request is OIDC as well as JAR compliant.

If I had an RP I would always construct OIDC auth requests like that, to
make sure they comply with OIDC as well as the new JAR spec (and will
not have issues with servers which implement both specs but are not able
to "switch" behavior for some reason).

Vladimir

On 23/09/2020 14:58, Takahiko Kawasaki wrote:
> Hi Vladimir,
>
> Thank you for your reply. It sounds that your opinion is "`scope`
> request parameter must exist outside the request object even if JAR
> applies if the authorization request is an OIDC request". I'm on the
> fence on this topic and just wondered whether those who had wanted to
> remove `response_type` outside the request object (although doing it
> was a breaking change) would want to remove `scope` outside the
> request object too with the same motivation (although I don't remember
> well what was the motivation). JAR dares to drop `response_type`, so
> it would not be surprising to see that JAR dares to drop `scope`
> (including `openid`) too.
>
> OIDC Core 1.0 requires `response_type`, but JAR allows omission of the
> parameter if the parameter is included in the request object.
>
> If we applied the same logic, we would be able to state:
>
> OIDC Core 1.0 requires `scope` (including `openid`), but JAR allows
> omission of the parameter if the parameter is included in the request
> object.
>
> In terms of `response_type`, practically speaking, JAR has modified
> OIDC Core 1.0. Because JAR has already been allowed to go so far as
> that point, I would say it is difficult to find a convincing reason
> not to allow omission of `scope`.
>
> AFAIK, in the context of OIDC Core 1.0, parameters that are required
> to exist outside a request object even if they are included in the
> request object are `client_id`, `response_type` and `scope`. Because
> `client_id` is mandatory in JAR (it has become mandatory after
> long discussion), discussion for the parameter is not needed. Because
> the community has already reached consensus that `response_type` can
> be omitted, discussion for the parameter is not needed, either. What
> I've brought here is discussion for `scope`, hopefully the last
> parameter that is affected by JAR.
>
> Again, I'm on the fence on this topic. However, because logical
> conclusion (at least of mine) is that JAR should allow omission of
> `scope` (it also should be noted that JAR's basic rule prohibits
> referring to request parameters outside a request object), I want to
> see explicit consensus if `scope` (including `openid`) outside a
> request object is still required even after JAR is enabled.
>
> In short, my question is "Should `scope` be omitted?" I guess that the
> conclusion will affect the official conformance suite.
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
>
>
> On Tue, Sep 22, 2020 at 5:59 AM Vladimir Dzhuvinov
> <vladimir@connect2id.com <mailto:vladimir@connect2id.com>> wrote:
>
>     Hi Taka,
>
>     On 21/09/2020 20:12, Takahiko Kawasaki wrote:
>>     If we allow JAR (JWT Secured Authorization Request) to relax the
>>     requirement of `response_type` request parameter (outside a
>>     request object) from mandatory to optional, should we relax the
>>     following requirement of `scope` request parameter stated in OIDC
>>     Core 1.0 Section 6.1, too?
>>
>>     ----------
>>     Even if a scope parameter is present in the Request Object value,
>>     a scope parameter MUST always be passed using the OAuth 2.0
>>     request syntax containing the openid scope value to indicate to
>>     the underlying OAuth 2.0 logic that this is an OpenID Connect
>>     request.
>>     ----------
>>
>>     Otherwise, an authorization request like
>>     "client_id=...&request(_uri)=..." fails if the request object
>>     represents an OIDC request. An authorization request has to look
>>     like "client_id=...&request(_uri)=...&scope=openid" (`scope`
>>     including `openid` has to be given) even if the authorization
>>     server conforms to JAR and allows omission of `response_type`
>>     request parameter.
>
>     The bottom of section 5 has normative text which allows a JAR
>     compliant server to also comply with the OIDC spec with its own
>     style of request / request_uri parameter handling insofar as to
>     not reject other query params (such as scope, etc). The difference
>     is that according to JAR their values cannot be used or merged (as
>     in OIDC). But what can be reasonably done is to detect
>     scope=openid as you say and then switch to OIDC style request
>     object behavior.
>
>     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30#section-5
>
>>        The client MAY send the parameters included in the request object
>>        duplicated in the query parameters as well for the backward
>>        compatibility etc.  However, the authorization server supporting this
>>        specification MUST only use the parameters included in the request
>>        object.
>
>     The confusion between the two specs clears when it's seen that the
>     request objects in OIDC and JAR have different objectives.
>
>     In OIDC the objective is to enable securing of selected parameters.
>
>     In JAR the objective is to secure the entire authz request.
>
>
>>
>>     I think that implementers want to know consensus on this because
>>     it affects implementations. Has this been discussed yet?
>>
>>     Best Regards,
>>     Takahiko Kawasaki
>>     Authlete, Inc.
>
>
>     Vladimir
>