I haven't seen the proposed discovery stuff yet, but discovery in the SASL stuff will solve this, and so would discovery advertized from the resource server.
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] > On Behalf Of Torsten Lodderstedt > Sent: Wednesday, July 14, 2010 10:50 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] resource server id needed? > > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
