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

Takahiko Kawasaki <taka@authlete.com> Thu, 24 September 2020 14:08 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 1E31A3A0A3B for <oauth@ietfa.amsl.com>; Thu, 24 Sep 2020 07:08:06 -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 RBeL8rwmV7Mk for <oauth@ietfa.amsl.com>; Thu, 24 Sep 2020 07:08:03 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 818063A09DA for <oauth@ietf.org>; Thu, 24 Sep 2020 07:08:03 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id a17so3984884wrn.6 for <oauth@ietf.org>; Thu, 24 Sep 2020 07:08:03 -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=YYyWfRclyzYll4FkijVgX1UU8sgzVmKqr9FMZINn6TQ=; b=COmOMjRSi/Vn2WwH5cAO9/rSWm0c7nDzsREe1xJ0PQrQquoKTENKXrk8nIv+cnvjWq dnfqqiYrYCVYXduI9COvnY/DMywZ4RtoaE8OwZmlRO5bm6X8cmd0fR7mQZhsaNBTJXud G4AVUalEYd1LZgMd2bPB0aP0PjTAynlyi283mcPFjPcpsFClSdCUGnIHnUH7wAphUF8O KBZutUAo1GJwQ7EZN8aKI2Oj0oSEalwFD5Z6izXxCMzWswvG/MKpLP4HemnAoeoW2q/5 rBVJmrYmWTYhIdsSr9+RjgN1s8zjiotfXx5owUTeB87wK2zblE6tWUxFIBIElQ9jvFSy kVag==
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=YYyWfRclyzYll4FkijVgX1UU8sgzVmKqr9FMZINn6TQ=; b=dfZ4/XdclR69NYdaRN0tTeRaKK0rIHd3ll4XfuefQHL1d7VuqQu0NBAmKJHm+Pb9QL s0SOBDQZymAow+lVUS0wip8TRI2qZI5zWaFhrohLgxU2gIn4c1q0gyfk5IztMiVFGiuU cseXuHi7lmVbefvssJsVvw5lts9Z0YzmBxJ1lIGvY9/khGBY6Ug6sH1AMCerdKyUjMIk +2v8P9c6/JA04GctAiJjyUWeF8otdVKPFlLGFJjv2mTcSiiTTROMg8TbQMuKkgHDpMTL 1ki9QkouNY/1u65YOrPGPhrXLU2FI3zRPdIgEsz3FQ31zTa1L2jAwCNyBnxjgZT95HAe KCCA==
X-Gm-Message-State: AOAM531jhyuHsmKLBMIM14/Bde9a8WdwN9toga1AxXEZrzdkJJUcIsah yInOIPdzPKnkOGsy9W6jVuwhqYUuPsF4SnOAvgniH67fweTpHA==
X-Google-Smtp-Source: ABdhPJzEuv7giZqAPW0edklGBMPGq3a87v0zOwpwqlCL+zzoBdb06XjroxhRkY0XDd47OBUqYeHDXkeksllQH267owU=
X-Received: by 2002:a5d:660f:: with SMTP id n15mr5742370wru.103.1600956481652; Thu, 24 Sep 2020 07:08:01 -0700 (PDT)
MIME-Version: 1.0
References: <CAHdPCmOPwqbemgKsEALA0OvP+6z58N5eNA9WA_AsvDESNhE1kg@mail.gmail.com> <2cd8bfd1-f491-0086-979f-0527ccf16281@connect2id.com> <CAHdPCmPmABt6PyupuGZaofwp+jKy7aVEvUO488NdDzVFsD18BA@mail.gmail.com> <e13b2c81-8b8f-636d-7793-a4ab84dda66f@connect2id.com>
In-Reply-To: <e13b2c81-8b8f-636d-7793-a4ab84dda66f@connect2id.com>
From: Takahiko Kawasaki <taka@authlete.com>
Date: Thu, 24 Sep 2020 23:07:50 +0900
Message-ID: <CAHdPCmO0cfCZFy5V8QtY8ZN7Eon=AaYkxUpywTyhxGjS7R8eiA@mail.gmail.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000063db0805b00fbaf1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-JE3hIKqzcUGp6O57hq-Xkb721I>
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 14:08:06 -0000

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
<https://openid.net/specs/openid-financial-api-part-2-ID2.html#authorization-server>
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 <vladimir@connect2id.com>
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 <
> 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
>