Well it's easy enough for me to just make up a profile that follows rules I set. But since I don't think this need will be unique to myself, would you like me to write up a spec somewhere? (I've never written an IETF spec before) -- 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
On Mon, Jun 14, 2010 at 11:00 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > +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
