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 <e...@xmlgrrl.com>: > 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 >>>>> <tors...@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 >>>>> <tors...@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 >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
