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

[Aaron Parecki <[e-mail]>]

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