Thanks for the clarity Eran and I understand. -----Original Message----- From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Sunday, May 09, 2010 1:57 PM To: Foiles, Doug; OAuth WG Subject: RE: [OAUTH-WG] Autonomous clients and resource owners (editorial)
> -----Original Message----- > From: Foiles, Doug [mailto:doug_foi...@intuit.com] > Sent: Sunday, May 09, 2010 1:07 PM > To: Eran Hammer-Lahav; OAuth WG > Subject: RE: [OAUTH-WG] Autonomous clients and resource owners > (editorial) > > 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. You have three expirations: - The assertion - The access token - The refresh token (if present) The authorization server can issue an access token with any expiration but should not issue expiration later than that of the assertion. But still, there is nothing to prevent that. The authorization server may issue an access token with a shorter expiration than the assertion. In that case, it can require the use of the same assertion again to get another token, or it can issue a refresh token to accomplish the same thing. I reject the argument that the expiration policy (and getting it implemented correctly) has much to do with making a refresh token available to the server as a tool. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
