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