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

[William Denniss <[e-mail]>]

What you describe is incremental auth.

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)?

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.


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.


On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin <[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
>>
>> 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]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>