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