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
