Re: [OAUTH-WG] New OAuth I-D: Incremental Auth

[William Denniss <[e-mail]>]

On Fri, Jul 7, 2017 at 1:50 PM, Sergey Beryozkin <[e-mail]>
wrote:

> Hi
> On 07/07/17 18:56, William Denniss wrote:
>
>> What you describe is incremental auth.
>>
>> Thanks... FYI, I thought of doing some work around it after browsing
> through the Google docs; the line about the "asking to approve the purchase
> of the kitchen sink at the authentication time is a death of the modern
> web" (or something similar that I read on this list) was even more
> convincing :-)
>

I hear ya :-)

We ended up requiring that apps *don't* ask for the kitchen sink upfront in
our API policies
https://developers.google.com/terms/api-services-user-data-policy#request-relevant-permissions
. Definitely makes for a bad user experience if users don't know why they
are being asked to approve the request's scope.



>
> Aside: Do you return the "scope" in the token response as required when
>> the scope in the response is not identical to the request (§ 5.1 <
>> https://tools.ietf.org/html/rfc6749#section-5.1>, parameter: scope)?
>>
>> Yes, the token service is doing it by default for all the returned access
> tokens
>
> My only question is: does the client expect this?  The spec talks about
>> the authorization server *reducing* scope in a few places (in § 3.3 <
>> https://tools.ietf.org/html/rfc6749#section-3.3>, "The authorization
>> server MAY fully or partially ignore the scope requested by the client" and
>> § 10.3 <https://tools.ietf.org/html/rfc6749#section-10.3> "The
>> authorization server SHOULD take the client identity into account when
>> choosing how to honor the requested scope and MAY issue an access token
>> with less rights than requested.").  It never talks about *increasing*
>> scope (other than it can't be done during refresh).
>>
>> So I think some normative language around the potential to increase the
>> scope of the request for confidential clients (in either the way you
>> describe, or the way I described in the draft) is warranted.
>>
>> Open question: should we require an indication from the client if they
>> *want* the scope increase? That's what include_granted_scopes was designed
>> to do. To allow clients to specify if this is behavior they desire.
>>
> Right, I see how a proposed "include_granted_scopes" can make it non
> ambiguous
>
>>
>>
>> The more innovative part of the spec I think is the public (native app)
>> client incremental auth – as native apps cannot use the methods you
>> discuss, or the ones Google has supported for a while for confidential
>> clients. That said, if we write this – I think we may as well formally
>> document approaches for confidential clients too.
>>
>>
> thanks, Sergey
>
>>
>> On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     Hi
>>
>>     Re the confidential client: let me explain please how we
>>     experimented with this feature when the code flow is used.
>>
>>     1. Client requests a scope 'a' for a given User, it gets approved by
>>     the user, the clients gets a code and exchanges it for a token.
>>
>>     2. At some later stage Client requests a scope 'b' for the same user
>>     and if an access token for a given Client + User combination exists
>>     and the incremental authorization is supported (we use a different
>>     term for now) than the service finds out from this token that 'a'
>>     has already been approved and offers a consent screen where a user
>>     sees 'a' being selected and needs to approve 'b'.
>>
>>     3. User approves 'b'. The client gets a new code back and exchanges
>>     it for a new token which now has "a" and "b".
>>
>>     At this point a client has 2 tokens, one with the "a" scope and
>>     another with the "a" and "b" scopes and the assumption was that the
>>     client would itself remove the now redundant token with the scope
>>     "a" only.
>>
>>     I've just updated the code for the service itself do it on the
>>     client's behalf, optionally remove the scope "a" token so that the
>>     client can simply replace a reference to its scope "a" token with
>>     the new one (scopes "a" and "b") it will get after exchanging a code
>>     grant.
>>
>>     Is it an incremental authorization or something else completely :-) ?
>>
>>     One obvious difference, apart from the lower level implementation
>>     details, is that it is not a client which requests to include the
>>     already authorized scopes but the service does it itself if the
>>     configuration allowing for it is enabled
>>
>>     Thanks, Sergey
>>
>>
>>
>>
>>
>>
>>     On 05/07/17 18:17, William Denniss wrote:
>>
>>         Earlier this week I submitted the following I-D:
>>         https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth
>> <https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth>
>>
>>         The topic is incremental authentication (or incremental auth for
>>         short).  Incremental auth is used to enable clients to request
>>         just the scopes they need when they need them – rather than all
>>         upfront – while still only a maintaining a single authorization
>>         grant.
>>
>>         The I-D details two techniques used at Google, one that has been
>>         used for a while in confidential clients, and one that we
>>         launched recently as a new solution to deliver incremental auth
>>         for public clients.
>>
>>         I look forward to discussing this proposal with the working
>>         group. I plan to present this draft at IETF99, hope you can be
>>         there or watching the livestream!
>>
>>         I plan to ask for a call for adoption after that presentation.
>>         If you're interested in this topic I'd encourage you to read the
>>         draft (it's fairly concise!).
>>
>>         Best,
>>         William
>>
>>
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/oauth
>>         <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>     <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>>