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

[Torsten Lodderstedt <[e-mail]>]

Am 15.07.2010 20:14, schrieb Marius Scurtescu:
> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
> <[e-mail]>  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.