In this case, the assertion the client starts with is from Windows authentication, and the assertion is obtained from an Active Directory server that is inaccessible unless the client app is running on a computer currently connected to the corporate network. I imagine that assertion has a limited lifetime, and the client doesn't have access to it anyway since it is added to the HTTP request by the platform, and is a challenge-response based protocol and therefore cannot be replayed later.
So sure, I can read "SHOULD NOT" as a recommendation and do it anyway (using the standard parameter name refresh_token). The assertion itself being a challenge-response type thing in the transport itself, this profile seems to apply even less unless it can be worded to say the assertion can be found elsewhere. (there's precedence for this in the spec that talks about how client credentials can be found in any of multiple places but must only be found in ONE of them). Let me know what you think. If I need to invent my own profile I guess I can do that. -- 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 8:50 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote: > First, the spec says “SHOULD NOT issue a refresh token” which means, don’t > do it unless you have to. But what stops the client from keeping the same > assertion and reusing it later? > > > > As for using other methods for providing an assertion, you need to be more > specific about what you have in mind. But either way, you can extend the > token endpoint to support other ways of providing assertions. > > > > EHL > > > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Andrew Arnott > *Sent:* Monday, June 14, 2010 8:32 PM > *To:* OAuth WG (oauth@ietf.org) > *Subject:* [OAUTH-WG] Assertion flow: please add optional refresh_token in > response > > > > 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
