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

[William Denniss <[e-mail]>]

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 <[e-mail]> 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
> they are a paying customer.)
>
> --
> -jim
> Jim Willeke
>
> On Fri, Jul 7, 2017 at 9:03 PM, William Denniss <[e-mail]>
> wrote:
>
>>
>> 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-incrementa
>>>> l-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>
>>>>
>>>>
>>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>