The scalable oauth extension addresses multiple/additional resource authorizations using the same tokens: http://oauth.pbwiki.com/ScalableOAuth
- Praveen On Fri, Jan 30, 2009 at 9:08 AM, Krishna Sankar (ksankar) <[email protected] > wrote: > > Interesting ... > > IMHO, the scope (of the URL) determines the extend of capabilities > exposed (or can be accessed) via an OAuth mechanism. (I am working on a > few combinations of this to figure out the granularity) > > So if we say the scope as www.example.com/uc/vmail/1234, then only the > voice mail #1234 can be accessed. Also there is the expiration > associated with a token. Between these two, I think we can get very > granular as well as temporal. > > Of course www.example.com/uc/presence/* could potentially open up > presence of everyone in the company. > > Jorgito, did I miss something ? > > Cheers > <k/> > > |-----Original Message----- > |From: [email protected] [mailto:[email protected]] On Behalf > |Of Jorgito > |Sent: Friday, January 30, 2009 7:08 AM > |To: OAuth > |Subject: [oauth] Re: Distinction between Request Token and Access token > | > | > |Thank you both for your fast replies. > | > |Indeed, I was wrong when I said that the distinction between both > |tokens would dramatically increase the response time. I misunderstood > |the spec, as I thought that one pair Request Token -- Access Token > |only granted access to one protected resource (namely, one URL). I see > |that there are no limitations in that aspect, and a single pair of > |tokens grants access to multiple protected resources. > | > |I'm not sure whether this is good or not. Maybe in some Web > |applications it would be desirable a "finer grained" protocol that can > |grant access to some specific (and no more) resources. For example, > |instead of the canonical example of a photo hosting service I can > |think about a site hosting medical records - extremely confidential > |information. I mean, there is a BIG difference between allowing an > |application acting as Consumer to know if I've had a flu recently, and > |giving it free access to all the information concerning my health. > |This "all or nothing" approach taken in OAuth may not fulfill the > |requirements of some Web applications. > | > |And on the other, the problem of temporal states between tokens still > |remains. I don't know how this issue would affect to the performance > |of large-scale Web applications. In other words, does OAuth scale > |well? > | > |Thanks a lot for your help, I really appreciate it (receiving a PhD is > |easier with the help of a community ;-) ). Greetings, > | > |Jorgito > | > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
