Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

In our implementation we mostly record grants as per-user, per-client_id.
However, we treat public clients whose identity we can't verify as
ineligible for incremental auth. The reason is if a client is
counterfeiting another client, we don't want to return previous
authorizations (the user should at least have to grant permissions in the
context of this other counterfeiting application).  For a public client
where the return path can be guaranteed by the OS (e.g. Universal Links on
iOS), this rule can be relaxed, so it's more about public clients whose
identity cannot be verified (e.g. custom URI scheme, or localhost redirect).

I have an idea for how to solve those unverifiable clients too, where the
client would prove its previous authorization grant by providing the
current access token on the new "incremental" authorization request.

For verifiable clients, we have an option to "snowball" tokens and include
previous grants (with the exception of some scopes that need per-device
approval), using the non-standard param include_granted_scopes
<https://developers.google.com/identity/protocols/OAuth2WebServer#incrementalAuth>.
Such a request results in a new token being issued with potentially
increased scope, we don't automatically increase the scope of previously
issued tokens.

Perhaps this group could consider standardizing Incremental OAuth. There
are valuable lessons & techniques that several people here have learnt and
implemented over the years, as shown by this thread. I might be willing to
put together a draft.

On Wed, Jan 27, 2016 at 9:11 AM, Sergey Beryozkin <sberyozkin@gmail.com>
wrote:

> Hi George
>
> Thanks. I think I'll need to spend more time on thinking about the way it
> has to be implemented, but I guess one thing I realize is that using only
> access tokens as records for this purpose is not ideal/generic.
>
> That said, it is not clear to me that a per-instance level consent makes
> sense only when the dynamic registration is used.
>
> Suppose we have a statically registered client, with the client id shared
> between 100 devices or even confidential clients. I'm actually not sure how
> realistic it is that the same user works with more than one device sharing
> the same id, but assuming it is possible sometimes, and further, with
> incremental authentication in place,
>
> we can have a situation where while working on device1 a user has approved
> 'a' while on device2 - scope "b", with both devices sharing the same client
> id.
>
> May be I'm making it too complex :-)
>
> Thanks, Sergey
>
> On 27/01/16 16:53, George Fletcher wrote:
>
>> My recommendation, like the others, is to store consent by
>> client_id:user and then try and leverage dynamic client registration if
>> instance level consent is needed.
>>
>> On 1/27/16 11:43 AM, George Fletcher wrote:
>>
>>> Yes, I was thinking mostly of "native apps"... though you bring up a
>>> good point. It would be great if "installable" web apps could do
>>> dynamic client registration:)  I suppose for a "public" client that is
>>> loaded onto a device, the "installation" process could obtain a new
>>> client_id for that instance. Cookies might work, or have the app
>>> generate a unique identifier and use that in conjunction with the
>>> client_id?
>>>
>>> Thanks,
>>> George
>>>
>>> On 1/27/16 11:07 AM, Thomas Broyer wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jan 27, 2016 at 1:54 PM George Fletcher <gffletch@aol.com
>>>> <mailto:gffletch@aol.com>> wrote:
>>>>
>>>>     The difference might be whether you want to store the scope
>>>>     consent by client "instance" vs client_id application "class".
>>>>
>>>>
>>>> Correct me if I'm wrong but this only makes sense for "native apps",
>>>> not for web apps, right?
>>>> (of course, now with "installable web apps" –e.g. progressive web
>>>> apps–, lines get blurry; any suggestion how you'd do it then? cookies?)
>>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>