I don't have a need for anything beyond the scope parameter here.
On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt < [email protected]> 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 >>> <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
