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.
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. Prabath Siriwardena <prab...@wso2.com> 2012-10-08 12:00 收件人 zhou.suj...@zte.com.cn 抄送 Eve Maler <e...@xmlgrrl.com>, oauth@ietf.org, oauth-boun...@ietf.org 主题 Re: Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation Hi Zhou, Even though client_id is public that needs to be passed from the Authorization Server to the Resource Server. This does not happen in the normal OAuth flow. It only returns back the access_token. Please let me know if you need any further clarifications... Thanks & regards, -Prabath On Sun, Oct 7, 2012 at 8:03 PM, <zhou.suj...@zte.com.cn> wrote: Hi,Prabath I have read your proposal, and have some questions: why RS needs to get access token in client register stage; and why RS needs to get client-id from AS by exchanging access token (isn't client-id public?) Prabath Siriwardena <prab...@wso2.com> 2012-10-08 09:50 收件人 zhou.suj...@zte.com.cn 抄送 Eve Maler <e...@xmlgrrl.com>, oauth@ietf.org, oauth-boun...@ietf.org 主题 Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation Hi Zhou, Nice to see some common interest on this. Sure I will go through your proposal. Please find my proposal here [1]. I've added there the complete token flow, introducing a new grant type. [1]: http://blog.facilelogin.com/2012/10/proposal-resource-owner-initiated.html Thanks & regards, -Prabath On Sun, Oct 7, 2012 at 6:24 PM, <zhou.suj...@zte.com.cn> wrote: Hi, Praba I am also thinking on this subject, and published a draft on it. http://tools.ietf.org/id/draft-zhou-oauth-owner-auth-00.txt I'd like to have your opinion. Prabath Siriwardena <prab...@wso2.com> 发件人: oauth-boun...@ietf.org 2012-10-08 08:08 收件人 Eve Maler <e...@xmlgrrl.com> 抄送 oauth@ietf.org 主题 Re: [OAUTH-WG] Resource owner initiated OAuth delegation Hi Eve, Thanks for pointers.. I've been following the work done in UMA.. Sure.. will join the webinar... BTW .. I am not quite sure UMA addresses my use case. Even in the case of UMA it's client initiated or requestor initiated... Please correct me if I am wrong... but in OAuth specification there is no restrictions to identify the 'client' as a person, organization or as him self.. In my view - this is an extended grant type..which has two phases.. 1. Resource owner grants access to a selected a Client 2. Client requests the already available access token for him from the Authorization Server.[just like passing the refresh_token] WDYT ? Thanks & regards, -Prabath On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler <e...@xmlgrrl.com> wrote: Hi Prabath, As far as I know, OAuth itself generally isn't used to let one human resource owner delegate access to a different human resource owner. However, UMA (which leverages OAuth) does strive to solve exactly this use case, among other similar ones; we call this one "person-to-person sharing", and you can read more about it here: http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1 The UMA flow at run time still ends up being effectively "client-initiated" (we would say requesting-party-initiated, using a requester app) because the original resource owner (we call it an authorizing party) is no longer around by then. The authz party would set up policies at some point before going on vacation, and these polices would enable the requesting party to "qualify in" for access at run time, by supplying identity claims that get used in an authorization check by the authz server (authz manager). We'll be walking through UMA flows and demoing an extensive use case at a webinar on Wed, Oct 17. More info is here: http://tinyurl.com/umawg Hope this helps, Eve On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena <prab...@wso2.com> wrote: > Hi folks, > > I would like to know your thoughts on the $subject.. > > For me it looks like a concrete use case where OAuth conceptually does > address - but protocol does not well defined.. > > Please find [1] for further details... > > [1]: http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.html > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://RampartFAQ.com > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
