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
