Apologies for jumping in late.
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of zhou.suj...@zte.com.cn > Sent: Thursday, October 11, 2012 4:45 AM > To: Eve Maler > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation > > > 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. What may not be clear up-front from reading the UMA core spec is that there are 5 parties involved (AM, Alice/RO, Host, Bob (Requesting Party) and Bob's portal/platform (Requester)). Here's a more accurate picture: - I deposit my Child at the Kindergarten. - I delegate my old Grandmother to pick up the Child. - My Grandmother takes a taxi. - The taxi Driver acts as proxy to my old Grandmother who stays in the taxi. - The taxi Driver needs to show 2 forms of Delegation to the Teacher. - The Taxi driver walks the Child to the taxi. Bear in mind that my Grandmother now has to manage the delegation she gave the taxi Driver (plus the Scopes involved). /thomas/ > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
