Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response

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.hardt@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 <andrewarnott@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
>
>