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. Thanks & regards, -Prabath > > > *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*<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* <prab...@wso2.com>*>* > > 2012-10-08 09:50 > > 收件人 > *zhou.suj...@zte.com.cn* <zhou.suj...@zte.com.cn> > 抄送 > Eve Maler <*e...@xmlgrrl.com* <e...@xmlgrrl.com>>, > *oauth@ietf.org*<oauth@ietf.org>, > *oauth-boun...@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 > *<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*<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*<http://tools.ietf.org/id/draft-zhou-oauth-owner-auth-00.txt> > I'd like to have your opinion. > > *Prabath Siriwardena <**prab...@wso2.com* <prab...@wso2.com>*>* > 发件人: *oauth-boun...@ietf.org* <oauth-boun...@ietf.org> > > 2012-10-08 08:08 > > 收件人 > Eve Maler <*e...@xmlgrrl.com* <e...@xmlgrrl.com>> > 抄送 > *oauth@ietf.org* <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*<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*<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*<http://tinyurl.com/umawg> > > Hope this helps, > > Eve > > On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena > <*prab...@wso2.com*<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 > *<http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.html> > > > > -- > > Thanks & Regards, > > Prabath > > > > Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732> > > > > *http://blog.facilelogin.com* <http://blog.facilelogin.com/> > > *http://RampartFAQ.com* <http://rampartfaq.com/> > > _______________________________________________ > > OAuth mailing list > > *OAuth@ietf.org* <OAuth@ietf.org> > > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth> > > > Eve Maler > *http://www.xmlgrrl.com/blog*<http://www.xmlgrrl.com/blog> > * > **+1 425 345 6756* <%2B1%20425%20345%206756> * > http://www.twitter.com/xmlgrrl* <http://www.twitter.com/xmlgrrl> > > > > > > -- > Thanks & Regards, > Prabath > > Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732> * > > **http://blog.facilelogin.com* <http://blog.facilelogin.com/>* > **http://RampartFAQ.com* <http://rampartfaq.com/> > _______________________________________________ > OAuth mailing list* > **OAuth@ietf.org* <OAuth@ietf.org>* > **https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth> > > > > > -- > Thanks & Regards, > Prabath > > Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732> * > > **http://blog.facilelogin.com* <http://blog.facilelogin.com/>* > **http://RampartFAQ.com* <http://rampartfaq.com/> > > > > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > * > **http://blog.facilelogin.com* <http://blog.facilelogin.com/>* > **http://RampartFAQ.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
