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 <wdenn...@google.com> wrote: > > On Fri, Jul 7, 2017 at 1:50 PM, Sergey Beryozkin <sberyoz...@gmail.com> > 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 <sberyoz...@gmail.com >>> <mailto:sberyoz...@gmail.com>> 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 >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >>> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
