It seems to me that if one auth server can create tokens for a diverse set of resource servers, then why not have different user authorization endpoint URLs for each type of resource server, as an added differentiator for the scope (a namespace, if you will)?
So suppose one auth server serves two different photo services, both using overlapping scopes such that a client requesting access of some scope is otherwise ambiguous between which resource server the client needs access to. The auth server that serves both resource servers could have two end user authorization endpoints: http://auth.server.org/authorize?resourceserver=1 http://auth.server.org/authorize?resourceserver=2 And that way the auth server knows exactly what the client needs. The only scenario this doesn't allow for is for a user to authorize a client's access to *both* resource servers in one redirect. If this were an issue, perhaps you can apply a namespace-like prefix to each scope substring: rs1:photo:read rs2:photo:read Which would serve a similar purpose. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > no one else in the group having an opinion on this topic? > > > > Am 15.07.2010 20:14, schrieb Marius Scurtescu: >> >>> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt >>> <tors...@lodderstedt.net> wrote: >>> >>>> As I have written in my reply to Marius's posting. I'm fine with >>>> including >>>> server ids in scopes. But this requires a definition of the scope's >>>> syntax >>>> and semantics in the spec. Otherwise, scope interpretation (and server >>>> identification) will be deployment specific. >>>> >>> Sure, it is deployment specific, but why is that an issue? >>> >>> In your case, the authz server and all the resource servers are >>> managed by the same organization, right? >>> >>> Do clients need to be aware of the actual resource server? >>> >>> You can probably create a separate spec that defines scope syntax for >>> this purpose, if really needed. Does it have to be in core? >>> >>> Marius >>> >> >> Solving the challenge I described in a deployment specific way is not an >> issue. But the consequence is that authz server, resource servers and >> clients are tight together. >> >> Let me ask you one question: Why are we working together towards a >> standard protocol? I can tell you my expectations: I hope there will be >> broad support not only by libraries, but also by ready-to-use services and >> clients, so we could integrate such services into our deployment easily. >> Moreover, I would like to see OAuth to be included in application/service >> protocols like PortableContacts, SIP, WebDAV, IMAP, ... >> >> So what if I would like to use standard clients to access our services? >> Using scopes for specifying resource server id's in this case is also simple >> - if you take an isolated view. But since scopes may be used to specifiy a >> lot of other things, like resources, permissions, and durations, handling >> w/o a more detailed spec will in practice be impossible. >> >> Suppose a WebDAV service for media data access. Any WebDAV client knows >> the WebDAV protocol (== interface), e.g. the supported methods (GET, PUT, >> POST, DELETE, COPY, MOVE) and how to traverse directories. So it is >> sufficient to configure the client with the URL of my personal web storage. >> To start with let's assume, scopes are used to designate resource servers >> only. So the server's scope could be "webstorage". >> >> WWW-Authenticate OAuth realm='webstorage' scope="webstorage" >> >> The client could just pass this parameter to the authz server and >> everything is fine. >> >> On the next level, let's assume the (future) WebDAV standard with >> OAuth-support uses one permission per method type. So the full scope could >> be as follows: >> >> WWW-Authenticate OAuth realm='webstorage' scope="webstorage:GET >> webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY >> webstorage:MOVE" >> >> Passing this scope w/o any unmodified to the authz server is not an issue. >> But this implies the client asks for full access to the users media storage. >> Since our client is a gallery application, it requires the "GET" permission >> only. How does the client know which of the scope values to pick for the >> end-user authorization process? It must somehow select "webstorage:GET". >> >> But how? >> >> In my personal opinion, clients should be enabled to interpret, combine >> and even create scopes. And yes, this should go to the core of the spec. >> >> regards, >> Torsten. >> >> >> >> >> _______________________________________________ >> 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
