I think it would be good to have both a guideline informative RFC as well as the oauth.net blog entry, former being more "formal" in the way of writing while the later can be more readable one.
Re: pestering factor -- Indeed, I am the one started to talk about "turning an internet dog into a Pavlov's dog" and agree that pestering the user too much is not good. As in EU DP Directive and forthcoming regulation, we should actually skip the dialogue if it falls into one of the "conditions for processing" (apart from the explicit consent condition). However, if it is asking something that is not required for the immediate processing, it should ask, and the user should be alerted that something fishy is happening. I am working on these notice and consent issues at ISO/IEC JTC 1/SC 27/WG 5 so if you are interested, please do join :-) Nat 2015-07-22 13:52 GMT+02:00 Phil Hunt <[email protected]>: > Agreed. > > I have heard it can be equally bad to pester the user every time a new > scope is needed. > > There’s a definite balancing problem. > > I don’t think this an OAuth issue; just a good user experience issue. > > Phil > > @independentid > www.independentid.com > [email protected] > > On Jul 22, 2015, at 11:35 AM, Nat Sakimura <[email protected]> wrote: > > IMHO, returning everything if scope is empty is a violation of the > collection minimization principle. From the privacy by Design point of > view, a lazy programmer sending an empty request should not cause the > maximal data returned. > > Now, as to the spec change is concerned, I agree with John that it is not > required. > However, a Best practice document would probably help the developers. > > Nat > > 2015-07-22 11:19 GMT+02:00 John Bradley <[email protected]>: > >> Slideshare did register all of those scopes as ones the client could ask >> for. >> >> Interpreting no scopes as all the ones the client has set as the ones it >> wants is probably not unreasonable. >> >> The problem is a combination of Slideshare over asking, perhaps because >> they don’t understand the default behaviour, and LinkedIn now allowing >> only some of the scopes to be returned. >> >> I think people are moving back to allowing people to deselect scopes. >> In Android m you can now deselect scopes that apps request, both at >> installation and after. >> >> One argument that people have put forward is that RP will ask for the >> minimum set of scopes to encourage the person to consent. However it >> seems that many RP decide to grab the maximum permissions on the grounds >> that people agree to it. >> >> I don’t know that any spec change is required, but perhaps some sort of >> education is. >> >> If users decline all on a regular basis then the RP will be motivated to >> change. >> >> John B. >> >> On Jul 22, 2015, at 11:08 AM, Nat Sakimura <[email protected]> wrote: >> >> Wow, that's the very opposite of Privacy by Design/Default >> recommendation. >> >> >> 2015-07-22 11:06 GMT+02:00 Justin Richer <[email protected]>: >> >>> According to the LinkedIn docs, that means they get all the scopes that >>> they registered for. >>> >>> — Justin >>> >>> On Jul 22, 2015, at 10:59 AM, Maciej Machulak <[email protected]> >>> wrote: >>> >>> It seems that they don't ask for scopes. >>> >>> The parameter is left blank: scope= >>> >>> Kind regards, >>> Maciej >>> >>> On 22 July 2015 at 10:26, Phil Hunt <[email protected]> wrote: >>> >>>> Do they explicitly ask for those scopes? Or do they leave scope to >>>> default that way. >>>> >>>> Phil >>>> >>>> On Jul 22, 2015, at 10:22, Justin Richer <[email protected]> wrote: >>>> >>>> This is a pretty clear case of SlideShare trying to grab too much. The >>>> LinkedIn API (which is their own proprietary thing, not OpenID Connect) >>>> does separate all the permissions into different scopes. However, the >>>> SlideShare app is asking for all of them, and LinkedIn doesn’t let you >>>> uncheck any boxes on the authorization screen. >>>> >>>> FWIW, the reason they want write access to your profile is to >>>> automatically add new SlideShare presentations that you upload to your >>>> LinkedIn profile page. You should still have the option of turning that >>>> off, or of turning on that functionality later. >>>> >>>> — Justin >>>> >>>> On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty < >>>> [email protected]> wrote: >>>> >>>> Hey Barry, >>>> >>>> From my observations with Facebook, it now has options added for you to >>>> select what resources from Facebook will get shared when authorizing access >>>> to other applications. You can click on each of the possibilities and >>>> strip it down. It appears to me that Facebook is managing that, so in your >>>> case, I *think* (and am open to be corrected) that LinkedIn needs to do >>>> something similar. Without those options, I also cancel out and just don't >>>> use the other app. >>>> >>>> Thanks, >>>> Kathleen >>>> >>>> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba <[email protected]> >>>> wrote: >>>> >>>>> Yesterday, someone sent me a link to some presentation slides that >>>>> he'd posted to SlideShare. I looked at them, and wanted to download >>>>> them as a PDF. In order to let me do that, SlideShare wants me to log >>>>> in. It gives me the options to log in via LinkedIn or Facebook. As >>>>> I'm one of the three people in the world without a Facebook account, I >>>>> clicked "LinkedIn". That got me an OAuth authorization screen, image >>>>> attached. >>>>> >>>>> Now, I don't know if this is SlideShare's fault for asking for too >>>>> much, or LinkedIn's fault for not providing enough granularity for >>>>> requests, but just LOOK at that list of what I'd be giving SlideShare >>>>> access to. The first few make sense: read my profile (the whole thing >>>>> or pieces of it, including contact information). But... access to my >>>>> connections? I'm not sure they'd like my exposing their identities to >>>>> SlideShare. Access to my private messages? EDIT MY PROFILE? Srsly? >>>>> >>>>> Of course, this isn't the fault of the OAuth protocol, really (though >>>>> one might argue that there's not enough guidance provided). But, >>>>> really, with implementations like this, I have to wonder what they're >>>>> thinking. >>>>> >>>>> I clicked "Cancel", of course, and asked the slide creator to send me >>>>> a PDF. >>>>> >>>>> Barry >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Kathleen >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> >>> -- >>> Maciej Machulak >>> email: [email protected] >>> mobile: +44 7999 606 767 (UK) >>> mobile: +48 602 45 31 66 (PL) >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
