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