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.
Also, the user identity is asserted to the authorization server *not*through an *assertion* parameter but using Kerberos (I assume) as part of the HTTP protocol, so perhaps the spec for the assertion flow can specifically allow for assertions to be carried as part of the transport? -- 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
