Are you envisioning the client makes a call to AD to get an assertion where the call is automagically authenticated as the user by NTLM?
What do you envision being the relationship between the AS and AD? What authority does the AS have? How long is the refresh token valid for? I think you have an interesting use case here, but it would be useful to step back and describe how the client got to the point you are envisioning per my last email. -- Dick On 2010-06-15, at 7:03 AM, Andrew Arnott wrote: > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
