(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 <prab...@wso2.com> 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..
>
> 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 <e...@xmlgrrl.com> 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
>
> On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena <prab...@wso2.com> wrote:
>
> > 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
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
> 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
