Subject: [OAUTH-WG] Resource owner initiated OAuth delegation

From: Prabath Siriwardena <[email-masked]>
Date: Sat, 6 Oct 2012 10:29:18 -0700

Hi folks,

I would like to know your thoughts on the $subject..

For me it looks like a concrete use case where OAuth conceptually does
address - but protocol does not well defined..

Please find [1] for further details...

[1]: http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.html

--
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

---

From: Eve Maler <[email-masked]>
Date: Sun, 7 Oct 2012 11:05:27 -0700

Hi Prabath,

As far as I know, OAuth itself generally isn't used to let one human resource owner delegate access to a different human resource owner. However, UMA (which leverages OAuth) does strive to solve exactly this use case, among other similar ones; we call this one "person-to-person sharing", and you can read more about it here: http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1

The UMA flow at run time still ends up being effectively "client-initiated" (we would say requesting-party-initiated, using a requester app) because the original resource owner (we call it an authorizing party) is no longer around by then. The authz party would set up policies at some point before going on vacation, and these polices would enable the requesting party to "qualify in" for access at run time, by supplying identity claims that get used in an authorization check by the authz server (authz manager).

We'll be walking through UMA flows and demoing an extensive use case at a webinar on Wed, Oct 17. More info is here: http://tinyurl.com/umawg

Hope this helps,

	Eve

On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: Prabath Siriwardena <[email-masked]>
Date: Sun, 7 Oct 2012 17:08:16 -0700

Hi Eve,

Thanks for pointers.. I've been following the work done in UMA.. Sure..
will join the webinar...

BTW .. I am not quite sure UMA addresses my use case. Even in the case of
UMA it's client initiated or requestor initiated...

Please correct me if I am wrong... but in OAuth specification there is no
restrictions to identify the 'client' as a person, organization or as him
self..

In my view - this is an extended grant type..which has two phases..

1. Resource owner grants access to a selected a Client
2. Client requests the already available access token for him from the
Authorization Server.[just like passing the refresh_token]

WDYT ?

Thanks & regards,
-Prabath

On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler <[email-masked]> wrote:

> Hi Prabath,
>
> As far as I know, OAuth itself generally isn't used to let one human
> resource owner delegate access to a different human resource owner.
> However, UMA (which leverages OAuth) does strive to solve exactly this use
> case, among other similar ones; we call this one "person-to-person
> sharing", and you can read more about it here:
> http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1
>
> The UMA flow at run time still ends up being effectively
> "client-initiated" (we would say requesting-party-initiated, using a
> requester app) because the original resource owner (we call it an
> authorizing party) is no longer around by then. The authz party would set
> up policies at some point before going on vacation, and these polices would
> enable the requesting party to "qualify in" for access at run time, by
> supplying identity claims that get used in an authorization check by the
> authz server (authz manager).
>
> We'll be walking through UMA flows and demoing an extensive use case at a
> webinar on Wed, Oct 17. More info is here: http://tinyurl.com/umawg
>
> Hope this helps,
>
>         Eve
>
> > [1]:
> http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.html
> >
> > --
> > Thanks & Regards,
> > Prabath
> >
> > Mobile : +94 71 809 6732
> >

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: [email-masked]
Date: Mon, 8 Oct 2012 09:24:31 +0800

Hi,  Praba

  I am also thinking on this subject, and published a draft on it.
http://tools.ietf.org/id/draft-zhou-oauth-owner-auth-00.txt
  I'd like to have your opinion.

Prabath Siriwardena <[email-masked]> 
发件人:  [email-masked]
2012-10-08 08:08

收件人
Eve Maler <[email-masked]>
抄送
[email-masked]
主题
Re: [OAUTH-WG] Resource owner initiated OAuth delegation

Hi Eve,

WDYT ?

Thanks & regards,
-Prabath 

The UMA flow at run time still ends up being effectively 
"client-initiated" (we would say requesting-party-initiated, using a 
requester app) because the original resource owner (we call it an 
authorizing party) is no longer around by then. The authz party would set 
up policies at some point before going on vacation, and these polices 
would enable the requesting party to "qualify in" for access at run time, 
by supplying identity claims that get used in an authorization check by 
the authz server (authz manager).

Hope this helps,

        Eve

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Prabath Siriwardena <[email-masked]>
Date: Sun, 7 Oct 2012 18:50:33 -0700

Hi Zhou,

Nice to see some common interest on this. Sure I will go through your
proposal.

Please find my proposal here [1]. I've added there the complete token flow,
introducing a new grant type.

[1]:
http://blog.facilelogin.com/2012/10/proposal-resource-owner-initiated.html

Thanks & regards,
-Prabath

On Sun, Oct 7, 2012 at 6:24 PM, <[email-masked]> wrote:

>  *Prabath Siriwardena <[email-masked]>*
> On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler <[email-masked]*<[email-masked]>>
> wrote:
> Hi Prabath,
>
> sharing", and you can read more about it here: *
> http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1*<http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1>
>
> webinar on Wed, Oct 17. More info is here: *http://tinyurl.com/umawg*<http://tinyurl.com/umawg>
>
> Hope this helps,
>
>         Eve
>
> On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena <[email-masked]*<[email-masked]>>
> wrote:
>
> > Hi folks,
> >
> > [1]: *
> *<http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.html>
> >
> > --
> > Thanks & Regards,
> > Prabath
> >
> > Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732>
> >
> > *http://blog.facilelogin.com* <http://blog.facilelogin.com/>
> > *http://RampartFAQ.com* <http://rampartfaq.com/>
> > [email-masked]* <[email-masked]>
> > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
>
>
> Eve Maler                                  *http://www.xmlgrrl.com/blog*<http://www.xmlgrrl.com/blog>
> *
> **+1 425 345 6756* <%2B1%20425%20345%206756>                         *
> http://www.twitter.com/xmlgrrl* <http://www.twitter.com/xmlgrrl>
>
>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
> *
> **http://blog.facilelogin.com* <http://blog.facilelogin.com/>*
> **http://RampartFAQ.com* <http://rampartfaq.com/>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: [email-masked]
Date: Mon, 8 Oct 2012 11:03:08 +0800

Hi,Prabath

 I have read your proposal, and have some questions:

  why RS needs to get access token in client register stage;
  and why RS needs to get client-id from AS by exchanging access token 
(isn't client-id public?)

2012-10-08 09:50

收件人
[email-masked]
抄送
Eve Maler <[email-masked]>, [email-masked], [email-masked]
主题
Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation

Hi Zhou,

Please find my proposal here [1]. I've added there the complete token 
flow, introducing a new grant type.

[1]: 

Thanks & regards,
-Prabath

Hi,  Praba 

收件人

Hi Eve, 

WDYT ? 

Thanks & regards, 
-Prabath 

Hope this helps,

        Eve 

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Prabath Siriwardena <[email-masked]>
Date: Sun, 7 Oct 2012 21:00:37 -0700

Hi Zhou,

Even though client_id is public that needs to be passed from the
Authorization Server to the Resource Server. This does not happen in the
normal OAuth flow. It only returns back the access_token.

Please let me know if you need any further clarifications...

Thanks & regards,
-Prabath

On Sun, Oct 7, 2012 at 8:03 PM, <[email-masked]> wrote:

> *<http://blog.facilelogin.com/2012/10/proposal-resource-owner-initiated.html>
>
> Thanks & regards,
> -Prabath
>
> On Sun, Oct 7, 2012 at 6:24 PM, <[email-masked]*<[email-masked]>>
> wrote:
>
> Hi,  Praba
>
>  I am also thinking on this subject, and published a draft on it. *
> **http://tools.ietf.org/id/draft-zhou-oauth-owner-auth-00.txt*<http://tools.ietf.org/id/draft-zhou-oauth-owner-auth-00.txt>
>   *Prabath Siriwardena <[email-masked]* <[email-masked]>*>*
> 发件人:  [email-masked]* <[email-masked]>
>
> 2012-10-08 08:08
>
>   收件人
> Eve Maler <[email-masked]* <[email-masked]>>
> 抄送
> [email-masked]* <[email-masked]>
> 主题
> Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732> *
>
> OAuth mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
> *

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Eve Maler <[email-masked]>
Date: Mon, 8 Oct 2012 09:08:17 -0700

(I'm not seeing  Zhou's responses to you on the list, so I don't have the other proposal handy. Can Zhou or someone share the link?)

Your proposal seems to require that the requester/client register with the AS (through the RS) ahead of time as well as initiating the approach to the resource at access-request run time. This seems quite similar conceptually to UMA. The main difference, I think, is that "three-legged" OAuth pretty much assumes (though it doesn't strictly enforce) that the resource owner and the requesting party are the same person by virtue of authenticating to both the client app and the AS in a single virtual session (your step #1).

UMA anticipates total separation between resource owner/authorizing user Alice and requesting party/client operator Bob, and lets Alice set up policies entirely without Bob's presence, requiring only that he present claims at access-request time. It's more akin to enterprise access control than authentication-based consent in enabling this separation.

There's another example of cooking up an access token ahead of time: This is one way OpenID Connect achieves the "distributed claims" effect. If an OpenID Connect IdP isn't responsible for knowing a particular attribute, but a third-party attribute provider has registered the attribute's availability with this IdP, the IdP can let clients/RPs get access to an interim resource that contains an attribute pointer and a pre-cooked access token for using at the actual attribute provider. But again, OpenID Connect implicitlly assumes the "same user" across clients and sessions and web apps.

My belief is that judiciously mixing UMA and OpenID Connect (and AXN) -- each of them already mixes in a lot of OAuth! -- could get us to a generically applicable claims-based authorization system for both attributes and arbitrary API calls.

	Eve

On 7 Oct 2012, at 5:08 PM, Prabath Siriwardena <[email-masked]> wrote:

> Hi Eve,
> 
> Thanks for pointers.. I've been following the work done in UMA.. Sure.. will join the webinar...
> 
> BTW .. I am not quite sure UMA addresses my use case. Even in the case of UMA it's client initiated or requestor initiated...
> 
> Please correct me if I am wrong... but in OAuth specification there is no restrictions to identify the 'client' as a person, organization or as him self.. 
> 
> 2. Client requests the already available access token for him from the Authorization Server.[just like passing the refresh_token]
> 
> WDYT ?
> 
> Thanks & regards,
> -Prabath 
>

---

From: [email-masked]
Date: Tue, 9 Oct 2012 09:24:11 +0800

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.

  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. 

2012-10-08 12:00

收件人
[email-masked]
抄送
Eve Maler <[email-masked]>, [email-masked], [email-masked]
主题
Re: Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation

Hi Zhou, 

Thanks & regards,
-Prabath

Hi,Prabath 

收件人
[email-masked] 
抄送

Hi Zhou, 

[1]: 

Thanks & regards, 
-Prabath 

Hi,  Praba 

收件人

Hi Eve, 

WDYT ? 

Thanks & regards, 
-Prabath 

Hope this helps,

       Eve 

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Prabath Siriwardena <[email-masked]>
Date: Tue, 9 Oct 2012 05:35:56 -0700

> 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.

> 3. Client accesses the protected resource on behalf of the Resource Owner.
There needs to be an step to facilitate client registration.

Thanks & regards,
-Prabath

> On Sun, Oct 7, 2012 at 8:03 PM, <[email-masked]*<[email-masked]>>
> wrote:
>
> Hi,Prabath
>
> [email-masked]* <[email-masked]>
> 抄送
> Eve Maler <[email-masked]* <[email-masked]>>, [email-masked]*<[email-masked]>,
> [email-masked]* <[email-masked]>
> 主题

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: [email-masked]
Date: Wed, 10 Oct 2012 09:49:48 +0800

Hi，Prabath

2012-10-09 20:35

收件人
[email-masked]
抄送
Eve Maler <[email-masked]>, [email-masked], [email-masked]
主题
Re: Re: Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation

Hi， Prabath 

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.

Process One: 

Process Two: 

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

收件人
[email-masked] 
抄送

Hi Zhou, 

Thanks & regards, 
-Prabath 

Hi,Prabath 

收件人
[email-masked] 
抄送

Hi Zhou, 

[1]: 

Thanks & regards, 
-Prabath 

Hi,  Praba 

收件人

Hi Eve, 

WDYT ? 

Thanks & regards, 
-Prabath 

Hope this helps,

      Eve 

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Eve Maler <[email-masked]>
Date: Wed, 10 Oct 2012 15:20:12 -0700

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, [email-masked] wrote:

>  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 
> 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. 
>   
> 
> 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 
> 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

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 10 Oct 2012 15:35:25 -0700

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 <[email-masked]> 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 Mon, Oct 8, 2012 at 6:24 PM, <[email-masked]*<[email-masked]>>
> wrote:
>
> Hi， Prabath
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Eve Maler <[email-masked]>
Date: Wed, 10 Oct 2012 15:54:51 -0700

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 <[email-masked]> 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..
>

---

From: [email-masked]
Date: Thu, 11 Oct 2012 08:40:46 +0800

Hi, Eve,
   The requester you described corresponds to Client in OAuth, so it is 
still client initiated delegation, not what Prabath wants.

2012-10-11 06:54

收件人
Prabath Siriwardena <[email-masked]>
抄送
[email-masked], "[email-masked] WG" <[email-masked]>
主题
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:

".... 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...

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

Hi Eve,

Thanks & regards,
-Prabath

On Wed, Oct 10, 2012 at 3:20 PM, Eve Maler <[email-masked]> 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.

Eve

Hi，Prabath 

收件人
[email-masked] 
抄送

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. 

Process One: 

Process Two: 

Thanks & regards, 
-Prabath 

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Eve Maler <[email-masked]>
Date: Wed, 10 Oct 2012 20:31:05 -0700

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, [email-masked] wrote:

> 
> Hi, Eve, 
>    The requester you described corresponds to Client in OAuth, so it is still client initiated delegation, not what Prabath wants. 
> 
> 
>

---

From: [email-masked]
Date: Thu, 11 Oct 2012 16:44:40 +0800

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.

2012-10-11 11:31

收件人
[email-masked]
抄送
"[email-masked] WG" <[email-masked]>, Prabath Siriwardena 
<[email-masked]>
主题
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

Hi, Eve, 

收件人

Eve 

Hi Eve, 

Thanks & regards, 
-Prabath 

Eve 

Hi，Prabath 

收件人
[email-masked] 
抄送

Hi， Prabath 

Process One: 

Process Two: 

Thanks & regards, 
-Prabath 

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 11 Oct 2012 15:44:03 +0000

Apologies for jumping in late.

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of [email-masked]
> Sent: Thursday, October 11, 2012 4:45 AM
> To: Eve Maler
> Cc: [email-masked] WG
> Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation
> 
> 
> Hi,Eve
> 
> 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/

> 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
> 
> 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."
> 
> (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.
> 
> 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
> 
> I have gone through UMA spec but failed to find any case which
covers
> this scenario - in a resource owner initiated manner..
> 
> 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.
> 
> 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
> 
> 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.
> 1. Resource Owner registers to-be-delegated clients and
corresponding
> RSs at AS, i.e., a long term delegation contract is stored at AS
> 
> Client is directed by RS to AS to obtain access-token,AS may request
RO
> to authenticate and confirm the
> access-token request

---

From: Eve Maler <[email-masked]>
Date: Thu, 11 Oct 2012 09:59:54 -0700

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