returning access token would suffice in this flow, from my point of view.

regards,
Torsten.


Am 27.04.2010 um 08:33 schrieb Brian Eaton <bea...@google.com>:

From my perspective, the main thing is that the assertion flow can be
used to connect existing authentication systems with APIs that are
using OAuth2 for authorization.

This will let us leverage existing trust relationships across systems.

Note that this breaks, however, if the flow returns a refresh token.
Refresh tokens are a new trust relationship, and they require
additional user/administrator involvement to manage.

Cheers,
Brian

On Mon, Apr 26, 2010 at 10:23 PM, Torsten Lodderstedt
<tors...@lodderstedt.net> wrote:
+1

we need the assertion flow for the same purpose. Can we add a variant of the
flow to section "End User Credentials Flows"?

regards,
Torsten.

Am 26.04.2010 23:17, schrieb Chuck Mortimore:

+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 spe cifically related to Eve’s comment below that suggests to me that the autono mous
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 ca se?
 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 resourc e 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



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to