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

[Torsten Lodderstedt <[e-mail]>]

Eve,

how does UMA plan to address resource servers during the OAuth end-user 
authorization process?

regards,
Torsten.

Am 29.07.2010 02:37, schrieb Eve Maler:
> Belatedly...  Sorry if I sound like a broken record on this, but: Most 
> of UMA's use involve letting a user introduce their various hosts 
> (UMA-flavored resource servers) to their single chosen "authorization 
> manager" (UMA-flavored authorization server), by treating the former 
> as a dynamically introduced OAuth client of the latter. This sounds an 
> awful lot like the question originally posed in this thread. We have 
> exactly the problem of figuring out how the host can tell the AM what 
> resources the AM should be protecting and what can be done to them, 
> which we've begun to solve with what we're calling a "resource 
> registration API" (RRAPI).
>
> (BTW, we're also working on an I-D to submit here that proposes a 
> solution for discovery/dynamic registration that meets our needs. 
> Hoping it can feed into Eran's discovery work.)
>
> Eve
>
> On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote:
>
>> thanks for sharing your thoughts.
>>
>> Differentiating resource servers by using different end-user 
>> authorization endpoint URLs is an option. I dont't know how this will 
>> work in conjunction with discovery, especially since this 
>> differentiation might by required on other endpoints, too. For 
>> example, if a client wants to obtain an access token for the 
>> end-user's credentials, it has to identify the resource server also 
>> on the tokens endpoint. There might be additional endpoint for other 
>> flows with similar requirements, e.g. the device flow.
>>
>> Based on your proposal, a derived solution could be to define a 
>> standard parameter "resourceserver" and to state how clients should 
>> use this parameter on the different endpoints. On the coding level, 
>> there would be no difference to your proposal :-) But the client 
>> would be able to construct such a URL on its own.
>>
>> Authorizing access for different resource servers is indeed an issue 
>> for me. How would you propose to add the namespace? Shall the scope 
>> obtained from the resource server already contain such a namespace 
>> are shall there be a rule to construct such namespaced-ed scopes in 
>> the spec?
>>
>> regards,
>> Torsten.
>>
>> Am 25.07.2010 19:11, schrieb Andrew Arnott:
>>> 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 
>>> <[e-mail] <mailto:[e-mail]>> 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
>>>             <[e-mail]
>>>             <mailto:[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] <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> Eve Maler
> http://www.xmlgrrl.com/blog
> http://www.twitter.com/xmlgrrl
> http://www.linkedin.com/in/evemaler
>