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

[Jim Willeke <[e-mail]>]

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-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>
>>>
>>>
>>>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>