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

[Torsten Lodderstedt <[e-mail]>]

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
>> <[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.
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth