Did I get you right? Your answer is: Oauth is not suited for deployments with different resource servers which rely in a single authz server?
I don't know why you categorize this as "complex". Is it so unusual to have let's say mail, webstorage, telephony, and payment services? At Deutsche Telekom, we operate such a deployment (with much more different resource servers) and I had hoped to move our token service towards OAuth v2. So would you recommend me zo stick to our proprietary protocol? regards, Torsten. Am 15.07.2010 um 00:39 schrieb Eran Hammer-Lahav <e...@hueniverse.com>: > If your deployment is that complicated, even my discovery proposal is not > going to help you... > > EHL > > > > On Jul 14, 2010, at 18:37, "Marius Scurtescu" <mscurte...@google.com> wrote: > >> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt >> <tors...@lodderstedt.net> wrote: >>> I have a question concerning the OAuth philosophy: How many resource servers >>> may be managed by a single OAuth authorization server? (a) A single resource >>> server or (b) several of them exposing different resource types? >>> >>> If the answer is (b) then how is a particular resource server identified in >>> the protocol? Clients have Ids, end-users as well (at least in a future >>> protocol extension), but what about resource server Ids? >>> >>> I think resource servers must be identifiable in multi-server deployments >>> for several reasons: >>> - Interpretation of the scope parameter should be resource server specific - >>> "read" may have different meanings in mail and address book >>> - An authorization server probably wants to apply server-specific security >>> policy, e.g. different access token durations >>> - It will be possible to create special tokens per server >>> >>> I think we should introduce a resource server id in the authz and access >>> token request. >>> >>> Any thoughts? >> >> I think the scope fills this role. Scopes implemented as URIs, for >> example, allow the authz server to map them to resource servers. >> >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
