If the client/requesting party is literally acting on behalf of the initial RO,
then it would seem to me that this is closer to the discussions of
"redelegation" and Twitter Echo and such from the past. UMA's use cases have to
do with authorizing delegated access that is performed on behalf of the client
itself (the word "autonomous" from OAuth 1.0 springs to mind).
Eve
On 11 Oct 2012, at 8:44 AM, Thomas Hardjono <hardj...@mit.edu> wrote:
> 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
>
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
