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

Why can the client app access the AS to get an access token but not the corporate network to get a new assertion?

How does the client app get the assertion to begin with? How did delegation from the user happen?

Would you elaborate more on the use case so that we can understand the full trust model?

The assertion flow was intended for autonomous clients rather than user delegation -- hence Brian's response and mine that this is a different flow if the access token is for user delegation.

-- Dick

On 2010-06-15, at 6:58 AM, Andrew Arnott wrote:

> 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
> 
> 