With Doug in an all day mtg, we have not sync'd on this...so one of us may respond again on this topic.
I think I am +1 w/ Brian E. In the flow from SAML gateway to STS to protected resource, I don't see caching both an access and refresh token as getting me any efficiency. Certainly, it adds complexity to regression testing. I appreciate the desire for symmetry on the set of flows...refresh token seems like a place for asymmetry. BillK -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Chuck Mortimore Sent: Tuesday, April 27, 2010 9:06 AM To: Torsten Lodderstedt; Brian Eaton Cc: Foiles, Doug; OAuth WG Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial) Same here - we don't intend to issue refresh tokens for either of these flows, and we'll only be accepting 1 time use assertions. -cmort ________________________________________ From: Torsten Lodderstedt [tors...@lodderstedt.net] Sent: Tuesday, April 27, 2010 9:00 AM To: Brian Eaton Cc: Chuck Mortimore; Foiles, Doug; OAuth WG Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial) 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
