Thanks for your explanation. Yes, I totally agree with you from the perspective of technology. Technically, service providers can come up with whatever policies about scope of authorization, allowed operations, etc. However, one drawback is that users may get confused when they access different services protected by OAuth because these service providers may use different UIs, different terms (I mean wording), etc. So sometimes the user may not get the context of the displayed OAuth authorization page. They need to spend some time (maybe not trivial) to figure out what the sentences on the page mean exactly (e.g. who can access his/her data, which portion data is accessed, what operations are allowed). I have used some OAuth services. Most of the time, the description on the OAuth authorization page is really simple so that I cannot exactly know what will happen after I click the "grant access" button. From the page I can only tell some app wants to access my data. Nothing more. I guess this may be a reason why users tend to click through the whole process without careful reading. What I described matches your idea perfectly - "The problem has much more to do with providing a user experience that is 1) comprehensible and 2) not annoying." My question is whether there is any effort trying to come up with some kind of standardized terms/UIs/process flows to improve use experience of OAuth authorization process. Another questions is in protocol level (not UI level) whether OAuth community plans to come up with 1) basic standard data operations (read, write, etc. of course, service providers can extend this) 2) how to specify scope of data exposure (also needs to be extensible). I know there are many technical and non-technical difficulties to do it. I am curious because service provider-specific ways to do it make apps hard to interoperate :-(
Gerald On Sat, Mar 20, 2010 at 3:48 PM, Chris Messina <[email protected]> wrote: > Hi Gerald, > Your question is a good one — and gets at some of the challenges inherent in > user authorization models. Specifically: when a user grants authorization, > how do you effectively scope access and communicate that to the user? Should > you or the user need to later change the scope of authorization, how do you > do so? > However, the way that you've described the problem is actually accurate. In > fact, OAuth says nothing about how much (or how little) access a user MUST > grant on a per instance basis. The amount of access authorized is dependent > on the policies of the service provider and the user's relationship with the > service provider. Therefore, a single OAuth token could access as little as > your full name, say, or as much as all of your account details. OAuth says > nothing about the scope of a given authorization instance. > So technically, there's nothing to stop OAuth from behaving as you've > described. > The problem has much more to do with providing a user experience that is 1) > comprehensible and 2) not annoying. While many people have said that they > would love to have granular access and control over who has access to their > data, in practice we find that people tend to click through authorization > screens without really reading them. Getting people to take more care in > authorizing third party access to their data would be a great thing, but is, > for better or worse, outside the scope of OAuth. > Chris > > On Sat, Mar 20, 2010 at 10:58 AM, Gerald <[email protected]> wrote: >> >> Hi, all >> I have been following OAuth work for some time. Also I have >> developed some apps using OAuth. One problem I encountered often is >> granularity of access. In current spec, after a user accepts the >> access request from a third-party app, the app can access all of >> user's data in arbitrary way. It is helpful to allow users control 1) >> which portion of his/her data will be exposed to third-party apps 2) >> what operations are allowed (read? write? update? etc). >> I believe OAuth community must have considered this problem before. >> But it's not included in the spec. I wonder whether there has been >> serious discussions on this problem. >> Anyone can point me to some related resources/pages/threads? >> Thanks >> >> Gerald >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OAuth" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/oauth?hl=en. >> > > > > -- > Chris Messina > Open Web Advocate, Google > > Personal: http://factoryjoe.com > Follow me on Buzz: http://buzz.google.com/chrismessina > ...or Twitter: http://twitter.com/chrismessina > > This email is: [ ] shareable [X] ask first [ ] private > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/oauth?hl=en. > -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
