+1 Is there any A/B test kind of statistics on the improvement of the conversion of the incremental authz over kitchen sink authz? If there is, it would be a very good data to show to those people who want everything upfront.
Nat 2015-07-22 15:01 GMT+02:00 William Denniss <[email protected]>: > On the pestering topic, one way that can be avoided is by using > incremental auth to ask for permissions just-in-time. That pattern holds up > when new scopes are required for new features. By contextualising the > permission ask, it likely leads to higher conversion rates as users can > figure out why the information is being requested, and by being optional > the cost of denying the permissions is not so great (unlike when sign is > prevented through user rejection). > > Permission screens that ask for the kitchen sink just to sign you in are > the death of identity federation. > > On Wed, Jul 22, 2015 at 2:50 PM, Nat Sakimura <[email protected]> wrote: > >> 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 >> >> > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
