On Mon, Feb 2, 2009 at 9:23 AM, Jorgito <[email protected]> wrote: > > Krishna: that's exactly what I mean, granularity in time and > granularity in the space of resources. The granularity in time is > already implemented in OAuth, but the granularity in resources... > maybe it's implicit in some field of some message, but I can't find it > in the spec!
The granularity of resources isn't implicit in any field; it's up to the Service Provider to decide what resources can be accessed. How the Consumer and Service Provider agree on which resources to give access to (in the Authorization step), is entirely dependent on the Service Provider's API. The reasoning behind this is that while "scope" is a common approach, it's not the only approach. For example, I may want to simply limit access to "read-only/write-only/read-write", or maybe (e.g., for academic article databases) "link/abstract/full article", or any number of other possibilities and intersections. There's no way that OAuth could or should describe these possibilities. As far as the scalability of temporal states, the raw storage of OAuth tokens over time isn't an issue; for the largest organizations like Google, storage of key-value pairs is trivial and "infinitely" scalable. For smaller organizations with up to around 100 million OAuth tokens, a single modern database server should be able to easily handle the load, particularly if caching layers are employed. b. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
