Thanks for addressing my questions Eran. For the Assertion Flow I would assume the lifetime of the authorization grant would be the same with or without the refresh token support. It doesn't seem to me like the overall lifetime of the authorization grant would change based upon the use of the refresh token.
However I certainly do see that the usefulness of the refresh token is very questionable based upon wanting the authorization grant lifetimes to be short for the Assertion Flow. And providing the refresh token for this flow almost leads the resource provider in granting longer than recommended authorization grant lifetimes ... which ultimately should be avoided. Is this the point? Thanks. Doug -----Original Message----- From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Sunday, May 09, 2010 10:26 AM To: Foiles, Doug; OAuth WG Subject: RE: [OAUTH-WG] Autonomous clients and resource owners (editorial) > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Foiles, Doug > Sent: Sunday, May 02, 2010 8:41 AM > To: OAuth WG > Subject: Re: [OAUTH-WG] Autonomous clients and resource owners > (editorial) > > I wanted to poke on the idea of not allowing Refresh Tokens for the > assertion flow. How not leaving this up to the server to decide a bad thing? Clearly not all assertions will map directly to the OAuth token and expiration, so the token is already a different trust relationship. The current draft has a SHOULD NOT for refresh token. > And I am wondering if the assertion flow where the client is acting on behalf > of a user is on the list of things to be added??? This is a problem with the autonomous grouping, not the flow. > And I still don't see the corresponding flow in OAuth 2.0 for an OAuth 1.0 - 2 > Legged use case where clients are acting on behalf of a resource owner that > is not themselves. Will there be a flow to support this??? I can actually > see > how another type of "end user credentials flow" would work where the > credential is something different than the username and password. No. The 1.0 2-legged use-case was really an abuse of the OAuth signature method to make signed requests using a username and password (client credentials) instead of using Basic auth. In OAuth 2.0, you have to go through an additional step: the client first uses its client credentials to get a token (over HTTPS) and it uses that token to make requests (signed or not). EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
