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 <sberyoz...@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 <gffle...@aol.com >>>> <mailto:gffle...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
