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