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

William Denniss <wdenniss@google.com> Sun, 03 May 2020 22:48 UTC

Return-Path: <wdenniss@google.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 A4AC63A08E9 for <oauth@ietfa.amsl.com>; Sun, 3 May 2020 15:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 TfEO0_dpUxeW for <oauth@ietfa.amsl.com>; Sun, 3 May 2020 15:48:00 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 ED6223A0877 for <oauth@ietf.org>; Sun, 3 May 2020 15:47:59 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id z17so7412232oto.4 for <oauth@ietf.org>; Sun, 03 May 2020 15:47:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JJQRZ/yprfaY/nxe86bPrZMMk8ZwZgfapAB7WbWOli4=; b=uB5sLyKSoAxguSSzqQCzgZULUQBStCV2rf7gzO6XxzaXH4m/MgGQh6T6kVjvPMBI+F i9+PCBh7yJyAnqoOiFMUbwhvN3BgLynE6oKis4rh4sy1OR9/ls32hMRYXmtVcyEH5AoA MoIlQEm8Qczu0qqsRIc26cXW8W8QIiKTuNm9EZ+FT7CkqMa+X+zBbRcsJCuMv5Q36Jt7 plm7RPh+QZ8Fl3a3eTr+tA71AU8nCD5EhKwuvGUWLJphCuyps6/A7Npa3mRU1KR+neQF xRu7ob1ms9PzIoL41Y9dME+P97+6QKlu+BKP0eY+iEFy5AJRDsobEo/yhRmjrvS+YfNA 4evQ==
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=JJQRZ/yprfaY/nxe86bPrZMMk8ZwZgfapAB7WbWOli4=; b=CXR6VfBm2feNFrGvOrLGJ00qcAteSOprIF+YyM/5ZQtRr8NknbByBKO2xWYvBPYuP8 DfAJPNKAAVs8E4kXNocLQbiYlQsl/uagt97ZvMZAJ2ChLEwbEAts046ZLJWTkZL2DMgF /y+w3AbxLp1z2OIsAuNlA3If3anq9GULXP5V0+GxzNvqWuHcr2jlXCLdkjDWvKBWab3j s/QEbEOTt8jreXEPEp1VR26Wqif8MB7sST+MM3TAcIT9uPa1MGYgrLDkuh95scm8H5Lq QziDweXHuJgUIoPcOFtcQaUdHgrm1ugqPZZcqhomiRYHcDjFGwXwXoOI/LPov1NNpl7p XIcQ==
X-Gm-Message-State: AGi0PuZSFUj+GUgVThakrxbDEMpaNKJiulCKx84qKZLiNYU9wniQM8qh SQbR5A+bV/AQWvlYhAGUyiuljbWhvnbnYi6bD0wgga/x
X-Google-Smtp-Source: APiQypIHKvZplzSdkwbuXCa6E7mvaSiGZrqhXP1VKRkYyXLZ04F3g6moSW/QX2/YiZbuI2ZlclwhnDH0AG8DklXBddM=
X-Received: by 2002:a9d:4c88:: with SMTP id m8mr11352350otf.149.1588546078761; Sun, 03 May 2020 15:47:58 -0700 (PDT)
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> <CAGBSGjpxfywTNpkrCuZAjfSoWdu8v79BrF7ZveXR-2gpPf+P_w@mail.gmail.com>
In-Reply-To: <CAGBSGjpxfywTNpkrCuZAjfSoWdu8v79BrF7ZveXR-2gpPf+P_w@mail.gmail.com>
From: William Denniss <wdenniss@google.com>
Date: Sun, 3 May 2020 15:47:46 -0700
Message-ID: <CAAP42hApDN4R7HCsc72A5smPCA-H9gd8m3Qkph_gNdS9b=2GXA@mail.gmail.com>
To: Aaron Parecki <aaron@parecki.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bc35ea05a4c6348f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/eYfk3H5FLofW0XojLRa8paEq29o>
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: Sun, 03 May 2020 22:48:03 -0000

Aaron,

Thank you for your review.

My replies are inline:

On Thu, Nov 14, 2019 at 12:40 PM Aaron Parecki <aaron@parecki.com> wrote:

> 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
>
> Thanks for the feedback, I've fixed this in 04.


> 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.
>

Good idea, I've added an example. I also defined a dedicated error code for
the authorization server to use when denying for this reason.


> 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?
>

Essentially, incremental_authz_types_supported = ["public"] means that
"existing_grant" is supported, and ["confidential"], means that
"include_granted_scopes" is supported. ["public", "confidential"] means
they both are.

On consideration, I think this was a bit confusing so I've reworded it. I'm
going to consider it for another edit pass following tomorrow's meeting.

Best,
William


----
> 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 <(425)%20345-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
>