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

From: William Denniss <[email-masked]>
Date: Wed, 5 Jul 2017 10:17:48 -0700

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

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 7 Jul 2017 17:24:42 +0100

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:
> 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!
> 
> interested in this topic I'd encourage you to read the draft (it's 
> fairly concise!).
> 
> Best,
> William
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: William Denniss <[email-masked]>
Date: Fri, 7 Jul 2017 10:56:23 -0700

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 <[email-masked]>
wrote:

> Hi
>
> Re the confidential client: let me explain please how we experimented with
> this feature when the code flow is used.
>
> 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".
>
> 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.
>
> 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
>
>
>
>
>
>
>> 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

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 7 Jul 2017 21:50:53 +0100

Hi
> 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 :-)

> 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 
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 
> 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 
> *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
> document approaches for confidential clients too.

thanks, Sergey
> 
> On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin <[email-masked] 
> <mailto:[email-masked]>> 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.
> 
>         https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth <https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth>
> 
>         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
> 
> 
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/oauth>
> 
>

---

From: William Denniss <[email-masked]>
Date: Fri, 7 Jul 2017 18:03:09 -0700

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

> 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.

>> 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
>
>> the authorization server *reducing* scope in a few places (in § 3.3 <
>> https://tools.ietf.org/html/rfc6749#section-3.3>, "The authorization
>> <https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth>
>>

---

From: Jim Willeke <[email-masked]>
Date: Mon, 10 Jul 2017 12:15:13 -0400

I know we add scopes based on the Authorization Server determining that the
Resource Owner is also a "Paying Customer". (Well using OIDC so we KNOW
they are a paying customer.)

--
-jim
Jim Willeke

On Fri, Jul 7, 2017 at 9:03 PM, William Denniss <[email-masked]> wrote:

> 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.
>
>
>
>>
>>>         https://tools.ietf.org/html/draft-wdenniss-oauth-incremental
>>> -auth <https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth
>>> >
>>>

---

From: William Denniss <[email-masked]>
Date: Thu, 13 Jul 2017 11:08:00 -0700

Thanks everyone for your reviews and feedback so far!

I'm bumping this thread one last time before IETF99. Would be great if
enough people have some knowledge of the draft to put it to an adoption
call :-)  Once again, doc is here and it's a fairly light read!
https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth

I look forward to presenting it to you all in Prague.

On Mon, Jul 10, 2017 at 9:15 AM, Jim Willeke <[email-masked]> wrote:

> I know we add scopes based on the Authorization Server determining that
> the Resource Owner is also a "Paying Customer". (Well using OIDC so we KNOW
>>>> -auth <https://tools.ietf.org/html/draft-wdenniss-oauth-incrementa
>>>> l-auth>
>>>>