| 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] Use Cases | |
|---|---|---|
| From: | Scott Cantor (cant...@osu.edu) | |
| Date: | Nov 26, 2003 8:22:57 am | |
| List: | org.oasis-open.lists.security-services | |
without requiring any global protocol to manage it. With the ability to force re-authentication at a certain time after the previous authentication, through the protocol, they get even more control over this process. I've cc'd Scott who's working on the SSO requirements to make sure he sees this.
I guess the question I have is one I've seen raised before, namely what exactly does ForceAuthn mean? How can the IdP have that kind of control when there are authentication technologies that make it impossible to know for sure whether the user will even be prompted.
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.
Even basic-auth behaves this way, though the IdP can work around that one with a challenge header.
So even if you grant that the SP can somehow "bypass" what we would normally consider to be SSO processing, that's fairly distinct from actually reauthenticating the user in a real sense. Or is the implication that the IdP MUST insure that this happens and cannot rely on technologies that don't provide that assurance if the Force flag is present?
-- Scott






.bin, .doc