28 messages in org.oasis-open.lists.security-servicesRE: [security-services] Re: ForceAuth...| From | Sent On | Attachments |
|---|---|---|
| Beach, Michael C | Oct 23, 2003 12:49 pm |  .bin, .doc |
| John Kemp | Nov 24, 2003 1:58 pm | |
| Beach, Michael C | Nov 25, 2003 11:24 am | |
| Greg Whitehead | Nov 25, 2003 11:50 am | |
| Beach, Michael C | Nov 25, 2003 12:24 pm | |
| Greg Whitehead | Nov 25, 2003 12:32 pm | |
| John Kemp | Nov 26, 2003 6:20 am | |
| Scott Cantor | Nov 26, 2003 8:22 am | |
| John Kemp | Nov 27, 2003 7:49 am | |
| Scott Cantor | Nov 28, 2003 9:30 pm | |
| Conor P. Cahill | Nov 29, 2003 2:14 am | |
| Conor P. Cahill | Nov 29, 2003 2:25 am | |
| Conor P. Cahill | Nov 29, 2003 2:27 am | |
| John Kemp | Nov 29, 2003 5:54 am | |
| Conor P. Cahill | Nov 29, 2003 11:35 am | |
| Beach, Michael C | Nov 29, 2003 11:37 am | |
| John Kemp | Nov 29, 2003 11:52 am | |
| Beach, Michael C | Nov 29, 2003 11:59 am | |
| Beach, Michael C | Nov 29, 2003 12:03 pm | |
| Conor P. Cahill | Nov 29, 2003 1:46 pm | |
| Conor P. Cahill | Nov 29, 2003 2:59 pm | |
| Anthony Nadalin | Nov 30, 2003 5:23 pm | |
| Conor P. Cahill | Nov 30, 2003 7:18 pm | |
| Conor P. Cahill | Dec 1, 2003 4:16 am | |
| Anthony Nadalin | Dec 1, 2003 9:31 pm | |
| Conor P. Cahill | Dec 2, 2003 4:38 am | |
| Anthony Nadalin | Dec 3, 2003 4:36 am | |
| Conor P. Cahill | Dec 3, 2003 4:54 am |
| Subject: | RE: [security-services] Re: ForceAuthn (was Use Cases) | |
|---|---|---|
| From: | Scott Cantor (cant...@osu.edu) | |
| Date: | Nov 28, 2003 9:30:20 pm | |
| List: | org.oasis-open.lists.security-services | |
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 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.
So I guess I do think that ForceAuthn gives some kind of license to interact with the user, though maybe it's not mandating one. Very few authentication technologies could claim to be doing authentication and not interacting though. Not any, depending on your viewpoint.
Client certs are tops on that list, since the cert store usually caches the PIN and repeatedly authenticates with the key for a length of time, often controlled by the browser, not the IdP.
But this may be the case regardless of the setting of ForceAuthn, no?
Yes, but if Force is off, there's no implication that the IdP has to be able to do anything specific re: forcing an interaction.
I think you are saying that ForceAuthn=true implies that the IdP actually interact with the user, and that such an interaction is the only way of re-authenticating the user in a real sense.
At the very least, I think true implies the IdP *could* interact. Whether it's the only way, I'd hesitate to claim that. I'm not an expert in authentication at that end. I can't personally imagine anything that I'd feel satisfied with as a relying party.
And, I don't know that we could ever get that kind of effect within the protocol itself, for the reasons you have noted. But, I also think that in an environment where a "real" authentication is important to the SPs, that ForceAuthn may very well imply that the IdP will not depend on cached cert PINs or other methods where a user interaction is not required.
I would be in favor of codifying that. Or if not, AuthnContext should definitely take it into account. Probably already does.
-- Scott