Thanks Eve. The spec seems to be what I am looking for. I will definitely read the spec.
Gerald On Mar 20, 5:13 pm, Eve Maler <e...@xmlgrrl.com> wrote: > For what it's worth, the current UMA draft protocol (layered on WRAP for the > moment) does propose a way for a client to express to the authorization > server its desired scope of access, using a JSON format and presuming that > the API has been documented in a resource-oriented way (resource > loc-plus-method). This is all at a layer above WRAP/OAuth 2.0 at the moment, > but if it has wider interest, that would be very good to know as we refine > the details. > > More info is here: > > http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Prot...(see > step 2; the actual scope granted affects what may happen in step 3 as well, > if the UMA host offloads token validation to the UMA authz manager) > > This was discussed on the OAuth IETF mailing list a bit, as well. > > Eve > > On 20 Mar 2010, at 1:13 PM, Zhenhua Guo wrote: > > > > > 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 <chris.mess...@gmail.com> > > 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 <jen...@gmail.com> 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. > >> 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. > > > -- > > 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 > > athttp://groups.google.com/group/oauth?hl=en. > > Eve Maler > e...@xmlgrrl.comhttp://www.xmlgrrl.com/blog -- 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.
