First, the spec says "SHOULD NOT issue a refresh token" which means, don't do it unless you have to. But what stops the client from keeping the same assertion and reusing it later?
As for using other methods for providing an assertion, you need to be more specific about what you have in mind. But either way, you can extend the token endpoint to support other ways of providing assertions. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Andrew Arnott Sent: Monday, June 14, 2010 8:32 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Assertion flow: please add optional refresh_token in response For an application I'm building, the installed client app will have intermittent windows of time where it can obtain a (non-OAuth) assertion for user identity. During this time, it seems appropriate for it to use the assertion flow to obtain an OAuth authorization so that it can impersonate the user. So far this is just standard Assertion Flow stuff. But without a refresh_token, the app will break when the access token expires if the app doesn't have the ability at the moment (due to not being on the corporate network at the moment for example) to obtain a new assertion. Since the security model for this app would certainly allow for a refresh_token to be issued from the original OAuth authorization server exchange, this would solve it, if the spec didn't specifically ban such a parameter. Also, the user identity is asserted to the authorization server not through an assertion parameter but using Kerberos (I assume) as part of the HTTP protocol, so perhaps the spec for the assertion flow can specifically allow for assertions to be carried as part of the transport? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
