|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:||Conor P. Cahill (conc...@aol.com)|
|Date:||Dec 1, 2003 4:16:15 am|
Beach, Michael C wrote on 11/29/2003, 3:05 PM:
I was envisioning the SPs would communicate with the IdP, not necessarily with each other.
But if a group of SPs were to have a combined session that is independent of the IdP managed authentication session, the SPs would have to somehow indicate that they are part of the "session group" and events related to that group would need to be propagated to the members of the group, even if it was through a third party such as the IdP. So it does create a path for the SPs to communicate with each other.
It does, also, introduce a problem in that the SPs would have to somehow indicate that they were part of the same session for the user. If the SPs are closely related, they may fit the concept of "affiliations" that was introduced in ID-FF 1.2. This would enable the SPs to work together for the user (with user opt-in, of course), but you would still need the "SP group session" management stuff that doesn't exist in the current protocols.
Your comment about user financial sites is fundamentally what is driving my interest in this. I am looking for some way to provide increased security at such sites while allowing them to participate somehow in the SSO environment. The challenge seems to be to find some level of compromise that provides sensible, secure behavior from a user perspective without undue technical complexity and overhead.
This can easily be done with the current protocols.
If the desire for increased security is from the SP, then SP can submit a request to the IdP with a "stronger" authentication context or with the ForceAuthn attribute set. The SP can also look at the AuthenticationInstant in the assertion and determine if it is recent enough for its security policy.
If the desire for increased security is from the user, they can instruct the IdP to require a particular level of authentication and/or credential confirmation for AuthnRequests from that SP.
The IdP, of course, can have policies that do the same.
What the current specs don't do is manage idle time. However, John Kemp is working on a proposal where that could be implemented.