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....@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-boun...@ietf.org> on behalf of Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org> > Date: Friday, November 8, 2019 at 2:36 PM > To: William Denniss <wdenniss=40google....@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....@dmarc.ietf.org> wrote: > > > > On Wed, Sep 25, 2019 at 3:54 PM Brian Campbell > <bcampbell=40pingidentity....@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.tschofe...@arm.com> > wrote: > > Thanks for the correction; yes – the most recent version is -02 and I posted > an old link. > > > > > > From: Eve Maler <e...@xmlgrrl.com> > Sent: Donnerstag, 12. September 2019 16:16 > To: Hannes Tschofenig <hannes.tschofe...@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.tschofe...@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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
