On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott <andrewarn...@gmail.com> wrote: > 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.
I think this is a different use case than the one envisioned by most people who are using the assertion flow. I'm inclined to steer different use cases to different profiles. It makes it much easier to guide deployments, for example. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
