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

From: Eve Maler <[email-masked]>
Date: Sun, 1 Aug 2010 17:16:41 -0700

I'm not sure if you mean "address" as in "handle", or "address" as in "uniquely label", but... UMA's first step involves a user-delegated introduction of a resource server to an authorization server as a special kind of client of it, using an OAuth2 web server flow with dynamic client registration as necessary. As part of this overall process, the resource server can tell the authorization server specifically which resource URLs are protected thereby (one way to do this is to wield its just-acquired access token at a protected resource registration endpoint at the authz server). Access tokens given to requesters (the real end-of-the-line clients) for accessing these resources are currently assumed to be given out on a per-resource-server basis, and each resource is uniquely associated with a single resource server and uniquely protected by a single authorization server, so there is no ambiguity. I suppose a resource server namespace could allow for higher-order aggregation as discussed below but I would personally prefer baby steps when it comes to the amount of dynamicism we're already assuming...

If you want to follow along with the UMA work, we have floated a number of spec drafts for these portions of our Step 1, and should shortly (within a day or so) have a more fleshed-out resource registration draft ready. We're not just cataloguing the resource URLs, but also the possible methods for accessing them; our assumption to date, as noted previously on this list, has been that the simple set of HTTP methods can get everyone really far -- but mindful of the need in OAuth-land for arbitrary "space-delimited list of strings" for scope, the current nascent draft allows for this.

	Eve

On 28 Jul 2010, at 11:32 PM, Torsten Lodderstedt wrote:

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

Eve Maler
http://www.xmlgrrl.com/blog
http://www.twitter.com/xmlgrrl
http://www.linkedin.com/in/evemaler

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 3 Aug 2010 16:04:49 +0200

I mean address as in "uniquely label".

Based on your explanation I assume you address resources instead of resource servers. Correct? What parameter of the end-user authorization flow is used to indicate the resource URL to the authz server. The scope?

regards,
Torsten.

---

From: Eve Maler <[email-masked]>
Date: Tue, 3 Aug 2010 12:09:42 -0700

The "scope flow" is intended to carry this information, and the authz manager/server compares the requested scope to a known mapping of protected resources to resource servers. (We're still working out details, and also trying to keep up with the changes to the OAuth2 substrate...)

	Eve

Eve Maler