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] > <mailto:[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] >> <mailto:[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] >> <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] >>>>> <mailto:[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] >>>>> <mailto:[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] <mailto:[email protected]> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Kathleen >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >>> >>> >>> -- >>> Maciej Machulak >>> email: [email protected] <mailto:[email protected]> >>> mobile: +44 7999 606 767 <tel:%2B44%207999%20606%20767> (UK) >>> mobile: +48 602 45 31 66 (PL) >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ <http://nat.sakimura.org/> >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ <http://nat.sakimura.org/> > @_nat_en > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
