Return-Path: 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 ; 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 ; 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 ; Sun, 3 May 2020 15:47:59 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id z17so7412232oto.4 for ; 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: <736340BF-B33D-4407-81AF-532C947F1243@xmlgrrl.com> In-Reply-To: From: William Denniss Date: Sun, 3 May 2020 15:47:46 -0700 Message-ID: To: Aaron Parecki Cc: oauth Content-Type: multipart/alternative; boundary="000000000000bc35ea05a4c6348f" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 22:48:03 -0000 --000000000000bc35ea05a4c6348f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Aaron, Thank you for your review. My replies are inline: On Thu, Nov 14, 2019 at 12:40 PM Aaron Parecki 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 maintai= n" > * 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 =3D ["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 > wrote: > > > > A few issues I noticed: > > > > > > > > There is no normative text describing AS behavior when > include_granted_scopes is =E2=80=9Cfalse=E2=80=9D or omitted. I suggest a= dding the > following to the parameter=E2=80=99s definition in section 4: > > > > When =E2=80=9Cfalse=E2=80=9D or omitted, the authorization server SHOUL= D 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 =E2=80=9C[t]he authorization server MAY fully or parti= ally > ignore the scope requested by the client=E2=80=A6.=E2=80=9D I=E2=80=99m n= ot sure offhand how to > resolve that. > > > > > > > > Regarding section 6.1, I don=E2=80=99t think we can assume that an acce= ss_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 t= he > 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=E2=80=99m not sure we need normative changes, but some > non-normative guidance highlighting this would be helpful. > > > > [NIT] Extra =E2=80=9Cshould=E2=80=9D 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 I= oT > 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=E2=80=99t think there is a normativ= e fix for > this, but it should be called out as a new failure mode that gets > introduced when switching from bulk to incremental authorization. > > > > > > > > =E2=80=93 > > > > Annabelle Richard Backman > > > > AWS Identity > > > > > > > > > > > > From: OAuth on behalf of Brian Campbell > > > Date: Friday, November 8, 2019 at 2:36 PM > > To: William Denniss > > Cc: oauth > > 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 40google.com@dmarc.ietf.org> wrote: > > > > > > > > On Wed, Sep 25, 2019 at 3:54 PM Brian Campbell 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 o= f > 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 =E2=80=93 the most recent version is -02= and I > posted an old link. > > > > > > > > > > > > From: Eve Maler > > Sent: Donnerstag, 12. September 2019 16:16 > > To: Hannes Tschofenig > > 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 th= e > 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 th= e > 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 fi= le > 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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --000000000000bc35ea05a4c6348f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Aaron,

Thank you for your re= view.

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 i= nterchangeably.
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 "with= out the
client needing to..."
* Section 7.1: "an app could maintain" should be "a client s= hould maintain"
* Section 8.1: "an app may offer" should be "a client may of= fer", and
a few more times in that paragraph

Thanks for the feedback, I've fixed this in 04.
=C2=A0
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.
=C2=A0
Good ide= a, I've added an example. I also defined a dedicated error code for the= authorization server to use when denying for this reason.
=C2=A0=
Section 9: Does including "public" in the
"incremental_authz_types_supported" value mean that the AS suppor= ts
the "existing_grant" parameter? It's not clear whether that i= s a 1:1
correlation, since section 5 says that it is only "NOT RECOMMENDED&quo= t;
for public clients to automatically approve requests rather than "MUST=
NOT".
=C2=A0
This could use some clarification on what it means exac= tly when
an AS advertises support for incremental authz. If this value does not
mean the "existing_grant" parameter is supported, do we instead n= eed
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 =3D ["public&quo= t;] means that "existing_grant" is supported, and ["confiden= tial"], means that "include_granted_scopes" is supported. [&= quot;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 followi= ng tomorrow's meeting.

Best,
William=


----
Aaron Parecki
aa= ronparecki.com

On Fri, Nov 8, 2019 at 4:19 PM Richard Backman, Annabelle
<richanna=3D40amazon.com@dmarc.ietf.org> wrote:
>
> A few issues I noticed:
>
>
>
> There is no normative text describing AS behavior when include_granted= _scopes is =E2=80=9Cfalse=E2=80=9D or omitted. I suggest adding the followi= ng to the parameter=E2=80=99s definition in section 4:
>
> When =E2=80=9Cfalse=E2=80=9D or omitted, the authorization server SHOU= LD NOT include scopes that were not explicitly specified in the authorizati= on request.
>
> Having written the above, I realize it conflicts with Section 3.3 of 6= 749, which states =E2=80=9C[t]he authorization server MAY fully or partiall= y ignore the scope requested by the client=E2=80=A6.=E2=80=9D I=E2=80=99m n= ot sure offhand how to resolve that.
>
>
>
> Regarding section 6.1, I don=E2=80=99t think we can assume that an acc= ess_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 a= s well. End users may expect that to be the case, particularly if the exist= ing scopes are listed in the consent display alongside the additional ones = being requested. I=E2=80=99m not sure we need normative changes, but some n= on-normative guidance highlighting this would be helpful.
>
> [NIT] Extra =E2=80=9Cshould=E2=80=9D in the 4th sentence of 6.1.
>
> I disagree with the first sentence of section 8.2. If the process of r= equesting consent is particularly expensive (e.g., if the client is an IoT = device or otherwise has limited input/output and is using the device author= ization grant), then it may be appropriate for the client to determine whic= h features the end user wants to enable and make a single authorization req= uest for all of the necessary scopes.
>
> There is no guarantee that the resource owner in the incremental autho= rization grant is the same as the resource owner in the original authorizat= ion grant. For example, the end user may log into Account A originally, but= Account B for the incremental authorization, either intentionally or by ac= cident. As it stands, the client has no way of knowing that this has happen= ed. I don=E2=80=99t think there is a normative fix for this, but it should = be called out as a new failure mode that gets introduced when switching fro= m bulk to incremental authorization.
>
>
>
> =E2=80=93
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampb= ell=3D40pingidentity.com@dmarc.ietf.org>
> Date: Friday, November 8, 2019 at 2:36 PM
> To: William Denniss <wdenniss=3D40google.com@dmarc.ietf.org>
> Cc: oauth <oaut= h@ietf.org>
> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01<= br> >
>
>
> 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 tha= t was the only issue that jumped out at me.
>
>
>
>
>
> On Wed, Nov 6, 2019 at 6:15 PM William Denniss <wdenniss=3D40google.com@dmar= c.ietf.org> wrote:
>
>
>
> On Wed, Sep 25, 2019 at 3:54 PM Brian Campbell <bcampbell=3D40pingident= ity.com@dmarc.ietf.org> wrote:
>
> Just noticed that something is missing in https://tools.ietf.org/html/draft-ietf-oauth-incremen= tal-authz-02#section-5 where it has just, "(Section 4.1.4 of )&quo= t;
>
>
>
> 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 =E2=80=93 the most recent version is -0= 2 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<= br> >
>
>
> 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&g= t; wrote:
>
> Hi all,
>
>
>
> We are starting a WGLC on the "OAuth 2.0 Incremental Authorizatio= n" draft. You can find the document here:
>
> https://tools.ietf.org/html/dr= aft-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 c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n 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 c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n 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 privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited...=C2=A0 If = you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from you= r computer. Thank you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited..=C2=A0 If y= ou have received this communication in error, please notify the sender imme= diately 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
--000000000000bc35ea05a4c6348f--