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

Takahiko Kawasaki <taka@authlete.com> Wed, 23 September 2020 11:58 UTC

Return-Path: <taka@authlete.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 465AC3A0FB2 for <oauth@ietfa.amsl.com>; Wed, 23 Sep 2020 04:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
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 wsn8688NcCzr for <oauth@ietfa.amsl.com>; Wed, 23 Sep 2020 04:58:41 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222AA3A0FB1 for <oauth@ietf.org>; Wed, 23 Sep 2020 04:58:41 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id k15so20697989wrn.10 for <oauth@ietf.org>; Wed, 23 Sep 2020 04:58:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c7KrMsIQIry35B0TMzc2jJ5+3+2Rw7Yt8z6PghUR7z8=; b=eXshPl9nxfPx+aL/xwSUlkGLlOqmIEgreLQfRhk+KziFsiobsWI3u/vBGIXvDhu3ai ICVIp4cjXWmao9qoHhfH12vfZ9UuNVkM7OaAZKvsMiHF8Lw2hDYA9sw66tXQYf+l62ps j0xOOr3e6lUo31wBO8ItW2T3WtpE78zJhPYotCtbSCHlHCqLL6T6gZRvyiNYeZZDdfhD wiXhf4/KmbANYcPvK/UcWA/2MiTx9LBIsRxijrv8/8aER09CqsFWDyiL2qqlElzTkveP 4UMzjruT+b3DELBSbuNVao5wTnYfD9x2spf9kLj04HRTOvFkMJpwr/z9UktIMp1sAGAj uv6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c7KrMsIQIry35B0TMzc2jJ5+3+2Rw7Yt8z6PghUR7z8=; b=gghGupJEyZWDlQwWH1ksV8IEqL/lx9dDWRL4OFKUhxSr5IPv3DKkGb355sFd+/5Oqs c9MQ345QBF6dm1bF28yaU8LwKW9iA8YhfxMg5U7hdQUTnBC5gK04a9udHF24Krcem2w2 1jlZx6afj+uw4Cfe0ibhFhnb6aoB54LRUbFOhSvajYhM54ewdZ20yhCQDD7SNwCL/Adi fg+oaAGdzxHxZvw5o+7QRRBFPEA2r8WOp92t4ojy/FaTgsKFXBlusVwSOJgf+42VKNnU uG3qrQR9UYW7rwopF4NVpnm+H4D0AMKSBIcKAmdefIyKrSYhvV81uPMveYcpwWe+MH8L chfg==
X-Gm-Message-State: AOAM530oFSgY0QzLWYGpI4WApL7719+3MafENLwabvS/Y4SpQTllOYX5 EXNEtgtzSiQ/i5LqfKXC2Rt2iJ0YVHWY+uxFA/ocVapfQeq9z6Tu
X-Google-Smtp-Source: ABdhPJzGz/Pz69czM0PLiBSooexxUQa+ybDSGyi09xng7S0TzeNHBcN/C4EMEDoIGyWY5VweC3i2MKFo+JU3JhQATaY=
X-Received: by 2002:a5d:688b:: with SMTP id h11mr403102wru.319.1600862319352; Wed, 23 Sep 2020 04:58:39 -0700 (PDT)
MIME-Version: 1.0
References: <CAHdPCmOPwqbemgKsEALA0OvP+6z58N5eNA9WA_AsvDESNhE1kg@mail.gmail.com> <2cd8bfd1-f491-0086-979f-0527ccf16281@connect2id.com>
In-Reply-To: <2cd8bfd1-f491-0086-979f-0527ccf16281@connect2id.com>
From: Takahiko Kawasaki <taka@authlete.com>
Date: Wed, 23 Sep 2020 20:58:27 +0900
Message-ID: <CAHdPCmPmABt6PyupuGZaofwp+jKy7aVEvUO488NdDzVFsD18BA@mail.gmail.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e134ab05aff9cda6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/yS6Zs2b7pOuw1mOQFcNy7gcInzM>
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: Wed, 23 Sep 2020 11:58:43 -0000

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>
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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>