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

[John Bradley <[e-mail]>]

Some people want exactly that behaviour.  If the user approves scope A on device a and scope B on device b, they want both to have scopes A & B.

Given that many AS are custom built for a specific service this can work for them.   It really depends on the API/Service what policy you want.  

When doing a generic library if it is not selectable someone will complain because they wanted it the other way.

Personally I don’t like that approach but perhaps people like twitter etc know better.

John B.

> On Jan 27, 2016, at 2:11 PM, Sergey Beryozkin <[e-mail]> 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 <[e-mail]
>>>> <mailto:[e-mail]>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> 
> -- 
> Sergey Beryozkin
> 
> Talend Community Coders
> http://coders.talend.com/
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth