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

From: William Denniss <[email-masked]>
Date: Sun, 3 May 2020 15:47:46 -0700

Aaron,

Thank you for your review.

My replies are inline:

On Thu, Nov 14, 2019 at 12:40 PM Aaron Parecki <[email-masked]> 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=[email-masked]> 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 <[email-masked]> on behalf of Brian Campbell
> <bcampbell=[email-masked]>
> > Date: Friday, November 8, 2019 at 2:36 PM
> > To: William Denniss <wdenniss=[email-masked]>
> > Cc: oauth <[email-masked]>
> > 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=
> [email-masked]> wrote:
> >
> >
> >
> > On Wed, Sep 25, 2019 at 3:54 PM Brian Campbell <bcampbell=
> [email-masked]> 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 <
> [email-masked]> wrote:
> >
> > Thanks for the correction; yes – the most recent version is -02 and I
> posted an old link.
> >
> >
> >
> >
> >
> > From: Eve Maler <[email-masked]>
> > Sent: Donnerstag, 12. September 2019 16:16
> > To: Hannes Tschofenig <[email-masked]>
> > 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 <
> [email-masked]> 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
> > [email-masked]
> > 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
> > [email-masked]
> > 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
> > [email-masked]
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/oauth
>

---

From: William Denniss <[email-masked]>
Date: Sun, 3 May 2020 15:53:10 -0700

Posting this to the list with Naveen's permission, see his comment below,
and my response:

On Thu, Nov 7, 2019 at 12:51 AM Naveen Agarwal <[email-masked]> wrote:

> Hi William,
>
> One nit.. on page 5 I think "requires" should be "required"
>
> "If later the user interacts with
>    the calendar or contacts features then, and only then, should the
>    require*s* scopes be requested. "
>
>
I've fixed this in my staged copy, will land in version 05.

> Separately I think it may be worth adding  somewhere (with more privacy conscious users and awareness)
>
> that if authorization server does not show currently granted scopes, then a user may assume that the current set of scopes
>
> are all they are granting to this client. Leading to privacy issues.
>
>
Thank you for your review Naveen, I appreciate your feedback.

I added a section to address this topic, "Previously Granted Scopes" (in
version 04). One challenge is that this advice can only apply to clients
that can't be impersonated (like confidential clients), as otherwise the
display could be inaccurate.

> Also a server could revalidate existing scopes and a user could deny them. A client should be able to handle that.
>
>
It would be good to guide clients on this possibility, I agree. I added a
new section "Handling Scope Reductions" (in version 04) to discuss some of
these possibilities and how they should be handled.

Regards,
William

> Thanks
> Naveen

> On Wed, Nov 6, 2019 at 5:15 PM William Denniss <wdenniss=
>>>> *From:* Eve Maler <[email-masked]>
>>>> *Sent:* Donnerstag, 12. September 2019 16:16
>>>> *To:* Hannes Tschofenig <[email-masked]>
>>>> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01
>>>>
>>>>
>>>>
>>>> I think you mean
>>>> [email-masked] <[email-masked]>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> prohibited....  If you have received this communication in error, please
>>> attachments from your computer. Thank you.*