In UMA, we've got use cases for "person-to-service" sharing that can act much
like the user-delegated OAuth patterns of today (essentially introducing two
services to interact on your own behalf), and also use cases for
"person-to-person" sharing that involve a "separate resource owner", hence our
interest in the autonomous client pattern or a variant thereof. We allow the
original resource owner (we call them an authorizing user) to set policies
asynchronously at the authorization manager (a sort of enhanced/user-centric
authz server) that govern whether a requesting party can ultimately get a
token. So in our case, this is how the resource owner gives consent outside the
flow.
(BTW, the word "ownership" gets tricky in talking about resource access and
other "property rights", which are famously described as a "bundle of sticks"
to show that different parties might have different subsets of rights. E.g., in
some UMA use cases, the authorizing user obviously has the right to throttle or
audit who can see certain data, but they don't have the right to actually set
the value of that data. Reputation data, such as a credit score or a
third-party certification, is a classic example. It's hard to describe the data
subject in this case as a total "resource owner"...)
Eve
On 26 Apr 2010, at 2:17 PM, Chuck Mortimore wrote:
> +1.
>
> Our primary use-cases for the assertion flow are for clients acting on behalf
> of users, and not autonomously. I believe Eran already has this on his list
> of feedback when the assertion flow gets edited.
>
> We also have need for a 2 legged Oauth model, and are looking at the client
> credentials flow for exactly that purpose.
>
> -cmort
>
>
> On 4/25/10 10:34 AM, "Foiles, Doug" <doug_foi...@intuit.com> wrote:
>
> I have a bit of confusion on the Autonomous Client Flows … and specifically
> related to Eve’s comment below that suggests to me that the autonomous client
> is NOT ALWAYS the resource owner.
>
> Can the Autonomous Client Flows support clients that ARE NOT the actual
> resource owner? For example for an Assertion Flow where the Subject of the
> SAML assertion is a user identity (and the resource owner) and not that of
> the client.
>
> Is the intent of the Client Credentials Flow to support something like
> Google’s “OAuth for Google Apps domains” 2 Legged OAuth use case?
> http://code.google.com/apis/accounts/docs/OAuth.html.
>
> If the Autonomous Client Flows support clients that can act on behalf a
> resource owner that is not themselves … it then seems the resource owner
> must provide some level of consent outside the OAuth specific flow.
>
> Thanks.
>
> Doug
>
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eve
> Maler
> Sent: Friday, April 23, 2010 7:21 AM
> To: OAuth WG
> Subject: [OAUTH-WG] Autonomous clients and resource owners (editorial)
>
>
> Regarding the second comment I made below: I realized last night that
> Sections 3.7.1 and 3.7.2 get this more correct, by saying that an autonomous
> client represents a "separate resource owner". So Section 2.2 definitely
> needs a slight change, from:
>
>
>
> "...and autonomous flows where the client is acting for itself (the client is
> also the resource owner)."
>
>
>
> to something like:
>
>
>
> "...and autonomous flows where the client is acting on behalf of a different
> resource owner."
>
>
>
> Thanks,
>
>
>
> Eve
>
>
>
> On 21 Apr 2010, at 4:43 PM, Eve Maler wrote:
>
>
> Tacking this response to the end of the thread for lack of a better place to
> do it: The name "username" seems not quite apt in the case of an autonomous
> client that isn't representing an end-user. Would "identifier" be better?
> (Actually, it sort of reminds me of SAML's "SessionIndex"...) Or would the
> parameter be reserved for user-delegation flows?
>
>
>
> Speaking of autonomous clients, Section 2.2 -- among possibly other places --
> states that an autonomous client is also the resource owner, but that's not
> always the case, is it? The client might be seeking access on behalf of
> itself. (FWIW, I made roughly this same comment on David's first draft on
> March 21, and he agreed with my suggested fix at the time.)
>
>
>
> Eve
>
>
>
> Eve Maler
>
> e...@xmlgrrl.com
>
> http://www.xmlgrrl.com/blog
>
>
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
