Re: [OAUTH-WG] resource server id needed?

No hang on.  A single auth server should be able to handle man resource
servers.

It only gets hairy I think if you want multiple auth servers. 

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@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 
> <eran@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" 
> <mscurtescu@google.com> wrote:
> > 
> >> On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt 
> >> <torsten@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
> 