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+Protocol (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 at > http://groups.google.com/group/oauth?hl=en. > Eve Maler e...@xmlgrrl.com http://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.
