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

I don't have a need for anything beyond the scope parameter here.

On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt <
torsten@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
>>> <torsten@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
>