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 <sakim...@gmail.com> wrote: > > Wow, that's the very opposite of Privacy by Design/Default recommendation. > > > 2015-07-22 11:06 GMT+02:00 Justin Richer <jric...@mit.edu > <mailto:jric...@mit.edu>>: > 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 <maciej.machu...@gmail.com >> <mailto:maciej.machu...@gmail.com>> 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 <phil.h...@oracle.com >> <mailto:phil.h...@oracle.com>> 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 <jric...@mit.edu >> <mailto:jric...@mit.edu>> 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 >>>> <kathleen.moriarty.i...@gmail.com >>>> <mailto:kathleen.moriarty.i...@gmail.com>> 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 <barryle...@computer.org >>>> <mailto:barryle...@computer.org>> 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 >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Kathleen >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> >> >> -- >> Maciej Machulak >> email: maciej.machu...@gmail.com <mailto:maciej.machu...@gmail.com> >> mobile: +44 7999 606 767 <tel:%2B44%207999%20606%20767> (UK) >> mobile: +48 602 45 31 66 (PL) > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > 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 > 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