Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01

Aaron Parecki <aaron@parecki.com> Thu, 14 November 2019 20:40 UTC

Return-Path: <aaron@parecki.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 2708112002E for <oauth@ietfa.amsl.com>; Thu, 14 Nov 2019 12:40:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-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 5cjOVzpO5Cse for <oauth@ietfa.amsl.com>; Thu, 14 Nov 2019 12:40:39 -0800 (PST)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 AE686120072 for <oauth@ietf.org>; Thu, 14 Nov 2019 12:40:37 -0800 (PST)
Received: by mail-il1-x133.google.com with SMTP id d83so6579342ilk.7 for <oauth@ietf.org>; Thu, 14 Nov 2019 12:40:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=n6B2r/Ru+1hbWpDNBSk8oxJwd6fuwBalqqpPHbc0sQw=; b=li8ifSbX4TM8nIDzQgmtrokTT3bU/Kqm1lPegJbser3Ws+fUITczkuJHzuMLgSdPUR lr+vYDyK1NSZWc9q/6rnsaacEjePF+HgTHVxosm8V7sZAgm3dCPcr6jX2FgSh+0v2mv+ tm92cZQq3+tWNro4YpEYXaAkD/CjIWgHL3GIj/HMliVi7v308sy6HcX2eSi99gnafXj6 kULQuNiRWcZyG6NU8dw2Vzb0CDKNG7vyv1cm8h9Dci4W9SbmlY3VuDKxVBxJ9O3oRzA/ YGZVpjkFjHD0Dk6uPMz2FCwtJli6XIdy0RCPn97c4C1MUuSiuPo6gvu/q6Ynkr3rLbNq qbqw==
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:content-transfer-encoding; bh=n6B2r/Ru+1hbWpDNBSk8oxJwd6fuwBalqqpPHbc0sQw=; b=o/sKFoCLeGhJSxqhHYaxJ0/qpbAYHIoi6f1Y3MzDvtR9ikQhpq7MFV2XWrysLZmp8c ajf/34TsPcIarWtiXPQPXiFVf9+kmUxdIe0nexcsppNhGx/tHI7xJgPUVkmw++G8GHj4 A4xkFRLFf4ECy52pOqv4r6hbHDfBXAwJ6nomRd1X22QcEzsrFWHPsmI1FrUdvc5+k89B NV206ms5Jac2+Fdf36esRebhjVOtHRyAmkjfAuq6Xsc8Y7nSKK7g4EaVEOtAGm3OaQnr MHXxaHkKORsPKodT9pWbjZrterHO/gefqijGc9LQXIANMmn3g5R2s32qTN0exy3t9USL Q4dA==
X-Gm-Message-State: APjAAAUCl6ZkxeQ8E/uV9uIGzdD/2FCVo0JEwQySwo7L0IG765BYGt2H cSJ5cnIfvK4D3fmB82rGZ+wBkHEm/+s=
X-Google-Smtp-Source: APXvYqzfmrsT5PAaqn/MB5YaVa4DOizuzIfOk78pSGa8kQiwaU3KyBTzLqlkGs/CF6UzTOlqaWMbPA==
X-Received: by 2002:a05:6e02:d92:: with SMTP id i18mr3070268ilj.20.1573764036692; Thu, 14 Nov 2019 12:40:36 -0800 (PST)
Received: from mail-il1-f179.google.com (mail-il1-f179.google.com. [209.85.166.179]) by smtp.gmail.com with ESMTPSA id f73sm946589ild.59.2019.11.14.12.40.28 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Nov 2019 12:40:35 -0800 (PST)
Received: by mail-il1-f179.google.com with SMTP id q1so6580505ile.13 for <oauth@ietf.org>; Thu, 14 Nov 2019 12:40:28 -0800 (PST)
X-Received: by 2002:a92:5ac1:: with SMTP id b62mr12989271ilg.46.1573764027744; Thu, 14 Nov 2019 12:40:27 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR08MB5360BBDDDF8362B40C97AF18FAB10@VI1PR08MB5360.eurprd08.prod.outlook.com> <736340BF-B33D-4407-81AF-532C947F1243@xmlgrrl.com> <AM0PR08MB5345B19B0AF2304AE8E110CAFAB00@AM0PR08MB5345.eurprd08.prod.outlook.com> <CA+k3eCR_ga1c1Cts0RY6Vy8AEgwjD2TaqOeWStkwQ6udqnkn2Q@mail.gmail.com> <CAAP42hCf2fQO29q3vCH8U7sJWpQ94AiE4BCvMWqYxqxe-erYyw@mail.gmail.com> <CA+k3eCRZ8ySJYFDTb=NbMZ=oVuFrMr5h82uazPsOmjD=XDY6Xg@mail.gmail.com> <E996A4E7-5F72-485D-AB67-652BDA2B9C94@amazon.com>
In-Reply-To: <E996A4E7-5F72-485D-AB67-652BDA2B9C94@amazon.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Thu, 14 Nov 2019 12:40:16 -0800
X-Gmail-Original-Message-ID: <CAGBSGjpxfywTNpkrCuZAjfSoWdu8v79BrF7ZveXR-2gpPf+P_w@mail.gmail.com>
Message-ID: <CAGBSGjpxfywTNpkrCuZAjfSoWdu8v79BrF7ZveXR-2gpPf+P_w@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/wgbbpS3JvCgDseo9gy2M1KG_seY>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01
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, 14 Nov 2019 20:40:42 -0000

My comments below:

The term "client" and "app" appear in multiple places interchangeably.
Since "client" is the OAuth 2 term, the document should stick to that
and not use the more colloquial term, "app".

* Section 4: "without the app needing to..." should be "without the
client needing to..."
* Section 7.1: "an app could maintain" should be "a client should maintain"
* Section 8.1: "an app may offer" should be "a client may offer", and
a few more times in that paragraph

Section 8.2 mentions a pretty broad recommendation "... what would
reasonably be needed by a single feature" but then stops short. I feel
like this could use some elaboration perhaps with examples, since it
feels a bit too vague as is.

Section 9: Does including "public" in the
"incremental_authz_types_supported" value mean that the AS supports
the "existing_grant" parameter? It's not clear whether that is a 1:1
correlation, since section 5 says that it is only "NOT RECOMMENDED"
for public clients to automatically approve requests rather than "MUST
NOT". This could use some clarification on what it means exactly when
an AS advertises support for incremental authz. If this value does not
mean the "existing_grant" parameter is supported, do we instead need
some other way to indicate which type of incremental authz is
supported for public clients so that public clients know whether to
use existing_grant or include_granted_scopes?

----
Aaron Parecki
aaronparecki.com

On Fri, Nov 8, 2019 at 4:19 PM Richard Backman, Annabelle
<richanna=40amazon.com@dmarc.ietf.org> wrote:
>
> A few issues I noticed:
>
>
>
> There is no normative text describing AS behavior when include_granted_scopes is “false” or omitted. I suggest adding the following to the parameter’s definition in section 4:
>
> When “false” or omitted, the authorization server SHOULD NOT include scopes that were not explicitly specified in the authorization request.
>
> Having written the above, I realize it conflicts with Section 3.3 of 6749, which states “[t]he authorization server MAY fully or partially ignore the scope requested by the client….” I’m not sure offhand how to resolve that.
>
>
>
> Regarding section 6.1, I don’t think we can assume that an access_denied just indicates a rejection of the incremental request. Depending on the consent interface presented to the end user, it may make more sense for the AS to interpret the denial as a retraction of the existing grant as well. End users may expect that to be the case, particularly if the existing scopes are listed in the consent display alongside the additional ones being requested. I’m not sure we need normative changes, but some non-normative guidance highlighting this would be helpful.
>
> [NIT] Extra “should” in the 4th sentence of 6.1.
>
> I disagree with the first sentence of section 8.2. If the process of requesting consent is particularly expensive (e.g., if the client is an IoT device or otherwise has limited input/output and is using the device authorization grant), then it may be appropriate for the client to determine which features the end user wants to enable and make a single authorization request for all of the necessary scopes.
>
> There is no guarantee that the resource owner in the incremental authorization grant is the same as the resource owner in the original authorization grant. For example, the end user may log into Account A originally, but Account B for the incremental authorization, either intentionally or by accident. As it stands, the client has no way of knowing that this has happened. I don’t think there is a normative fix for this, but it should be called out as a new failure mode that gets introduced when switching from bulk to incremental authorization.
>
>
>
> –
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
> Date: Friday, November 8, 2019 at 2:36 PM
> To: William Denniss <wdenniss=40google.com@dmarc.ietf.org>
> Cc: oauth <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01
>
>
>
> You are welcome. I'm always happy to be able to help with a major contribution such as this one :)
>
>
>
> I did read through the draft for WGLC back in September though and that was the only issue that jumped out at me.
>
>
>
>
>
> On Wed, Nov 6, 2019 at 6:15 PM William Denniss <wdenniss=40google.com@dmarc.ietf.org> wrote:
>
>
>
> On Wed, Sep 25, 2019 at 3:54 PM Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
>
> Just noticed that something is missing in https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02#section-5 where it has just, "(Section 4.1.4 of )"
>
>
>
> Thank you for catching this Brian. It was meant to read Section 4.1.4 of RFC 6749.
>
>
>
> I've updated this in my local copy, will get posted in version 04.
>
>
>
>
>
> On Thu, Sep 12, 2019 at 8:40 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
>
> Thanks for the correction; yes – the most recent version is -02 and I posted an old link.
>
>
>
>
>
> From: Eve Maler <eve@xmlgrrl.com>
> Sent: Donnerstag, 12. September 2019 16:16
> To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01
>
>
>
> I think you mean https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02?
>
> Eve Maler (sent from my iPad) | cell +1 425 345 6756
>
>
> On Sep 11, 2019, at 4:22 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
>
> Hi all,
>
>
>
> We are starting a WGLC on the "OAuth 2.0 Incremental Authorization" draft. You can find the document here:
>
> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-01
>
>
>
> Please review the document and provide feedback.
>
>
>
> The WGLC will end September 25th, 2019.
>
>
>
> Ciao
>
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> 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._______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> 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.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth