+1 On 2010-06-14, at 9:02 PM, Brian Eaton wrote:
> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
