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 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 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 oa...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> oauth+unsubscr...@googlegroups.com.
>> 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 oa...@googlegroups.com.
> T
