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

Takahiko Kawasaki <> Wed, 21 October 2020 12:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F386C3A0AD6 for <>; Wed, 21 Oct 2020 05:24:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jRNPtbdhd820 for <>; Wed, 21 Oct 2020 05:24:37 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 305433A0AD4 for <>; Wed, 21 Oct 2020 05:24:37 -0700 (PDT)
Received: by with SMTP id c77so1932815wmd.4 for <>; Wed, 21 Oct 2020 05:24:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+op9Yt3gjHtsB+UpZq6TVYTne4XhaxvOlG7o2KLFJZk=; b=H31CZqQMMtNUGoHWUo1zkYCTTBxPAGXxKvHTeDQkv9UaawfCQUg+mcjVZ2SetJZeuS nz0Fkj5ZIDqeIosZ4jpsvxDH0xEe8hgS1en1ujfmaL3SDiAtvtn0GX6Ufy1m5D2I9EOx Y7QSspwywEgPdIhkpvRFU5PT/Yzf9C74clE78XnFtMtjCDdGRk372Q1vq6I1ksEMSgCd iVQuJ4qBCvRRJU1DTmvaQ6UEtOIOPLhYhnkqgsF6nyuzLc7QZcrY4XAr30YebH0Hm2lR VfZf6/ei9XhoSe3DyQJJ1lU5seEF8bWuY5gupatGPTOCL02f4F+tnoAaTjkEbuG1kbns aAtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+op9Yt3gjHtsB+UpZq6TVYTne4XhaxvOlG7o2KLFJZk=; b=gqudKnBSTWzBlSoOVka5CR0v4GHXY1w9dcThJO2DNO74k9qLOdR8f6sEse2NS7i/tP t7GggiNtWIE/UWfewc6dHugyeXtpGEBUuRP+nSdNrIGTaKBM7U6gPBLT0HhcT0AzrhNI i0HA85Xt00JNWIzV3mEsP+ykMRB9h23bxM53sngm+mp8tSSm0kZ5I9nYu09s1hkZHgEy V8k70rv0yQudWJw8i0B4B9bIVMWP91m+efytpi5Q94HgK+S1J3gdUvyxDyYuNktMD6Xp 1rcVWx0XZoR2a0qLZaSwJ5O8qQhY2/TFSgoPik8sYTEIv0BrjUhC1Ua21JXQf95/czT7 rJTQ==
X-Gm-Message-State: AOAM5326Nzm6oY3a4RmRAOopfJWca5j3ixK3ogWQpSIo7AkozLp6zoC3 vZsV/8eWOWvZJ4J8xpYA4YBZSQHpGLgsrXncZCiS0tuYywxhvqra
X-Google-Smtp-Source: ABdhPJzmSkjtsLVbxNy2GBjkQ/BoR2dYIfz5jqcAfbZUBb3PhMNZmWpmfbizZv47kzP+7Yx4zwQ5/cEnV3Wrn85V73E=
X-Received: by 2002:a1c:2b05:: with SMTP id r5mr3296560wmr.179.1603283074837; Wed, 21 Oct 2020 05:24:34 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Takahiko Kawasaki <>
Date: Wed, 21 Oct 2020 21:24:46 +0900
Message-ID: <>
To: oauth <>
Content-Type: multipart/alternative; boundary="0000000000002682cc05b22d6e20"
Archived-At: <>
Subject: Re: [OAUTH-WG] [JAR] scope parameter outside request object of OIDC request
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Oct 2020 12:24:40 -0000

"there seems to be a good consensus that servers must not require the

from FAPI Issue 315: PAR certification question - must servers allow
requests where scope/response_type only passed to PAR endpoint

A consensus has been reached which is enough at least for the conformance
suite. It is the same as my suggestion. Thank you for discussion.


On Wed, Sep 30, 2020 at 2:21 PM Takahiko Kawasaki <> wrote:

> So, my suggestion is "When JAR compatible behaviors are employed, AS
> implementations should not require that an OIDC request come with `scope`
> query/form parameter when the request uses a request object." (NOTE: "an
> OIDC request" implies that the request object contains `scope` including
> `openid`.)
> Any thoughts?
> Taka
> On Thu, Sep 24, 2020 at 11:07 PM Takahiko Kawasaki <>
> wrote:
>> Hi Vladimir,
>> Just FYI. To be exact, FAPI (version 1) Part 1 (Read-Only) does not
>> require all request parameters be put duplicately in a request object. It
>> is FAPI (version 1) Part 2 (Read-Write) (Section 5.2.2
>> <>
>> Clause 10) that has the requirement. In the context of FAPI Part 1, a
>> request object does not have to be used. One more note is that parameters
>> inside a request object and parameters outside a request object are merged
>> (as they are in OIDC Core 1.0) when the authorization request is being made
>> for FAPI Read-Only APIs (not for FAPI Read-Write APIs).
>> Taka
>> On Thu, Sep 24, 2020 at 7:14 PM Vladimir Dzhuvinov <
>>> wrote:
>>> 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 <
>>>> 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.
>>>>    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