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

[William Denniss <[e-mail]>]

Hi Glen,

Thank you for reviewing the draft. Replies inline:

On Wed, Sep 11, 2019 at 5:35 AM Glen Mazza <[e-mail]> wrote:

> In Section 6.1, Handling Denials of incremental authorization requests, I
> wonder if the resource owner should be provided the ability by the
> Authorization Server to reject not just the additional scope(s) but also
> all previously granted ones.  This would be to guard against the client
> withholding dubious permission requests at the outset that might indicate
> to the resource owner that the client isn't particularly reliable, scopes
> that if they were provided all at once at the beginning would have resulted
> in the user never approving any of them.  In the user is inclined to deny
> an additional permission request due to a newfound lack of trust, he may
> also want to immediately decline previously granted permissions as well.
>

It is definitely always the authorization server's prerogative to take such
an action. In my experience, this boils down to UX decisions made by the
authorization server. One way to implement this would be to remind the user
of previously granted scopes, and give them the opportunity to revoke them.
Or, you could do your suggestion of instantly revoking all scopes on the
denial of any one, however this may go against the user's wishes (they
might be happy to grant contacts, but not calendar, for instance, in much
the same way today on a mobile phone you may grant notifications, but
withhold location).

I don't think we need to change the spec normatively to enable such
behavior, since the server can already revoke tokens it issues. Clients
should detect this revocation during the next request to the resource
server, and handle it accordingly.

Perhaps we could add a discussion about these implementation choices for
Authorization Server


In Section 7.2, it seems odd for the Authorization Server to rely on the
> client to tell it what scopes has already been approved for it.  I would
> think there would need to be a mechanism for the Auth Server to verify that
> information, but given that, why not rely on that information directly
> instead of what the client would be informing it?
>

This section documents an alternative approach that clients can take today
(i.e. without needing this new specification). I'll illustrate with an
example. Let's say a website needs Contacts on day 1, and both Contacts and
Calendar on day 2, here's how you might implement that with pure RFC 6749:

Day 1. User performs an action that requires contacts access. The website
does an OAuth requests for contacts, which the user approves. Now the app
has one authorization (with its associated access token) for contacts.
Day 2. User performs an action that requires both calendar and contacts
access. The website knows that it already has contacts access, so it does a
new OAuth request only for calendar, which the user approves. Now the app
has two different authorizations, one for contacts, and one for calendar
(and 2 access tokens, and potentially 2 refresh tokens to keep track of).

When the app makes a request to the resource server, it needs to know which
authorization's access tokens to include on the request. This is what I
mean by the app "keep[s] a running record of all granted scope", basically
it needs to have an internal list of which token includes which scope,
something that is burdensome. The other option of course is to just ask for
all scopes up front (even the ones it may not need right then), which is
not an ideal user experience (as the user is asked to grant permission to
scopes unrelated to their current activity), and this is the problem we're
trying to solve with incremental authz.

This spec makes life easier for the confidential client to do incremental
authorization. An incremental authz flow instead looks like the following:

Day 1. User performs an action that requires contacts access. The app does
an OAuth requests for contacts, which the user approves. Now the app has
one authorization for contacts.
Day 2. User performs an action that requires both calendar and contacts
access. The app simply makes a request that includes both scopes. The
authorization server can see that contacts was already approved, so only
displays the new scope - calendar. The user approves, and a new
authorization grant is issued that includes *both* scopes. The app still
has one authorization, but now it includes the contacts and calendar scope.

Best,
William