RE: [security-services] Re: ForceAuthn (was Use Cases)

["Conor P. Cahill" <concahill@aol.com>]

Scott Cantor wrote on 11/29/2003, 12:36 AM:

 > > Well, your point is certainly well taken, but I guess I wasn't
 > > necessarily equating ForceAuthn with "InteractWithUser". To me, all
 > > this says is for the IdP to at least check the authentication status of
 > > the user, following *their* policy. This may include a user
 > > interaction, but as you point out below, it may not. So, perhaps the
 > > term 'ForceAuthn' is somewhat misleading?
 >
 > "checking authn status" sounds a little light for something that I
 > thought was meant to imply a bypassing of SSO.

I agree.  I like to think of ForceAuthn as the SP asking the IdP to do 
whateve it takes so that the IdP can update the AuthenticationInstant in 
the assertion at this time.

For a UserName/Password authentication, this means it is a challenge to 
the user.  For some other authentication methods (such as an X509 
certificate, the IdP can challenge the client, but the IdP doesn't have 
control what the client does with the user, so there may be a soe cases 
where there is no challenge to the user).

 > I have generally assumed that there was a connection between
 > ForceAuthn and IsPassive. They can't be easy  rolled into one
 > field, but setting both to true doesn't seem viable, so I think
 > they need to be under a co-constraint.

I agree, although I don't think we need to codify it other than to point 
out that IsPassive has the highest precedence.  In a guideline type 
document we could point out that it typically wouldn't make sense to 
have both set to true, but I don't see that we need to make that a 
requirement in the specification.

Conor