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
On 3 Aug 2010, at 7:04 AM, Torsten Lodderstedt wrote:
> 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.
>
>
>
> Am 02.08.2010 um 02:16 schrieb Eve Maler <[email protected]>:
>
>> 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 protected]> 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 protected]> 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 protected]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [email protected]
>>>>> 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
>>
Eve Maler
http://www.xmlgrrl.com/blog
http://www.twitter.com/xmlgrrl
http://www.linkedin.com/in/evemaler
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
