Hi,Eve "Having an RO literally being present to register a client operated by some third party still seems like an unnecessary constraint to me if the alternative is for RO to configure their preferences and then move on."
--I didn't catch the significance of it either. But I think Prabath's idea is not RO-initiated client registeration, but RO-initiated access token delegation. Let RO itself decide who is to be delegated is reasonable, and could be commonly seen in everday life. For example, I deposit my child at kindergarden, then when someone tries to take him outside of the kindergarden, the teacher will inform me "do you authorize this guy do it"---that is what OAuth currently do; But I may prefer not to be disturbed too often, I just send delegation statement to a few of persons, e.g., grandparents of my child, then when someone tries to take my child outside of the kindergarden, the teacher will ask him/her to show my delegation statement, no statement, no taking my child. ----that my understanding of RO-initiated delegation. Eve Maler <e...@xmlgrrl.com> 2012-10-11 11:31 收件人 zhou.suj...@zte.com.cn 抄送 "oauth@ietf.org WG" <oauth@ietf.org>, Prabath Siriwardena <prab...@wso2.com> 主题 Re: [OAUTH-WG] Resource owner initiated OAuth delegation Ah, right. I think I got this more correct in my initial post than in this last one. Here's how I'd address this: RO Alice controls the access by client/requester Bob by virtue of consenting at access token issuance time in Prabath's proposal, vs. setting policies that direct an online service to issue it when Bob approaches in UMA. Another way to say this is that access is RO-initiated in the first case and, perhaps, RO-directed in the second. Having an RO literally being present to register a client operated by some third party still seems like an unnecessary constraint to me if the alternative is for RO to configure their preferences and then move on. (Note that if the RO and the requesting party are the same person, the UMA flow looks pretty much like a regular OAuth flow because Alice can configure a policy that says "Only alice@gmail can get full-scope access to this resource", and if Alice herself shows up using any client and can prove she's alice@gmail (e.g. through OpenID Connect claims, something we've already profiled), she's good to go.) Eve On 10 Oct 2012, at 5:40 PM, zhou.suj...@zte.com.cn wrote: Hi, Eve, The requester you described corresponds to Client in OAuth, so it is still client initiated delegation, not what Prabath wants. Eve Maler <e...@xmlgrrl.com> 2012-10-11 06:54 收件人 Prabath Siriwardena <prab...@wso2.com> 抄送 zhou.suj...@zte.com.cn, "oauth@ietf.org WG" <oauth@ietf.org> 主题 Re: [OAUTH-WG] Resource owner initiated OAuth delegation Sure. We'll ultimately be publishing some case studies that will hopefully make this clearer, but the key place to start in the spec is here: http://docs.kantarainitiative.org/uma/draft-uma-core.html#r-h-attempt-access ".... The requester typically attempts to access the desired resource at the host directly (for example, when a human operator of the requester software clicks on a thumbnail representation of the resource). The requester is expected to discover, or be provisioned or configured with, knowledge of the protected resource and its location out of band. Further, the requester is expected to acquire its own knowledge about the application-specific methods made available by the host for operating on this protected resource (such as viewing it with a GET method, or transforming it with some complex API call) and the possible scopes of access." So the requester can initiate the request, with the following preconditions: - The host (RS) has registered this resource as protected with the authorization manager (AS). - The requester (client)/requesting party has learned the location and applicable API details of the resource out of band. The interactions among the host (RS), AM (AS), and requester (client -- potentially operated by a third party who is not the RO) are protected with various tokens. This is illustrated in the introduction with ASCII art... http://docs.kantarainitiative.org/uma/draft-uma-core.html#introduction The actual protected resource requires a "requester permission token" (RPT) associated with suitable authorization data. This is an UMA-specific construct -- admittedly not a true OAuth flow, though inspired by it! The AM presents a protection API to the host for registering protected resources; the API is protected by a plain-vanilla OAuth token called a protection API token (PAT). The AM also presents an authorization API to the requester, which is protected by a plain-vanilla OAuth token called an authorization API token (AAT). We're counting on dynamic client registration to be in place wherever deployers want true loose coupling. When the requester initiates a request, if it has no token at all, the host directs it to the AM to get first an AAT (which conveys Bob's authorization to use it and the AM in conveying identity claims to win authorization), and ultimately an RPT (which convey's Alice's authorization for Bob and this requester app to access the resource with specific scopes). Of course we're talking about an UMA-enabled requester here, but it can literally initiate an access request with zero tokens and ultimately get somewhere. We'll be demoing this whole thing next Wednesday in the webinar, including the dynamic client reg, the PAT, AAT, and RPT, the UX for the various parties interacting with systems, and even interesting app-level enhancements like notifying Alice that Bob has made an access attempt and inviting her to set up policies that let him in. Eve On 10 Oct 2012, at 3:35 PM, Prabath Siriwardena <prab...@wso2.com> wrote: Hi Eve, I have gone through UMA spec but failed to find any case which covers this scenario - in a resource owner initiated manner.. Can you please give some pointers..? Thanks & regards, -Prabath On Wed, Oct 10, 2012 at 3:20 PM, Eve Maler <e...@xmlgrrl.com> wrote: There are a number of implicit actions happening here that ideally should be accounted for. If Alice is the RO and Bob is operating the client, then when Bob accesses the protected resource it may not just be "on Alice's behalf" -- think of how people share calendar read/write access with other people today. Those with delegated access act on their own behalf, with the RO's permission. So the tuple represented by the access token is actually quite a bit bigger than usual. Since OAuth makes a simplifying assumption that gets it entirely out of this sort of business, the process of trying to shoehorn this use case into a single plain OAuth flow may end badly. Better would be an explicit recognition of the symmetry of Alice (with her user agent) on one side, and bob with his client on the other side. Not to sound like a broken record, but the UMA model takes this fully into account and has even gone a fair way down the path of considering the contractual and legal implications of such authorization. Since the client (along with its operator) has to register on the AS side anyway, having a clean model where it can do that without the RO's synchronous presence would be ideal. Otherwise I suspect it's impractical in normal use. Eve On 9 Oct 2012, at 6:49 PM, zhou.suj...@zte.com.cn wrote: Hi，Prabath Prabath Siriwardena <prab...@wso2.com> 2012-10-09 20:35 收件人 zhou.suj...@zte.com.cn 抄送 Eve Maler <e...@xmlgrrl.com>, oauth@ietf.org, oauth-boun...@ietf.org 主题 Re: Re: Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation On Mon, Oct 8, 2012 at 6:24 PM, <zhou.suj...@zte.com.cn> wrote: Hi， Prabath My question is since client-id is public, then it is a waste to get it by granting an access-token. And in step 2."Resource Owner grants access to a selected Client", RO logins in to select clients to be delegated, and RS redirects RO to AS to grant access token to client, to my understanding, in this process RO needs to authenticate to RS and then authenticate to AS, it is a bit complicated. In fact I did not want to disturb normal OAuth flow.. BTW yes.. it adds some overhead.. So - I would like to modify it - where the Resource Server sends the resource_owner_initiated as the scope - and based on the scope AS returns back client_id together with the access_token it self. I wonder if the following two processes could satisfy your case: Process One: 1. Resource Owner registers to-be-delegated clients and corresponding RSs at AS, i.e., a long term delegation contract is stored at AS 2. When Resource Owner requests Client to access its resource at RS, Client is directed by RS to AS to obtain access-token 3. Client accesses the protected resource on behalf of the Resource Owner. Process Two: 1. RO registers to-be-delegated clients at RS, i.e., a long term delegation contract is stored at RS 2. When Resource Owner requests Client to access its resource at RS, Client is directed by RS to AS to obtain access-token,AS may request RO to authenticate and confirm the access-token request 3. Client accesses the protected resource on behalf of the Resource Owner. There needs to be an step to facilitate client registration. Client could have registered at AS. RO just select clients from available clients list. This facilitating step still needed? Thanks & regards, -Prabath Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
