specifying logout endpojnt at the IDP

[Steven Carmody]

On 6/13/12 5:45 PM, Cantor, Scott wrote:
>
> This is more art than science, but the way it sort of works is that the
> built-in metadata elements are meant to refer to profiles that are
> associated with protocol "families" signaled in the
> protocolSupportEnumeration attribute on a role.
>
> While it doesn't technically break anything to pick a custom binding and
> use that in an element to signal that it's something "special", the intent
> is that if it's not SAML 2 protocol, you also define a custom protocol
> string and put that in the enum if you reuse the built-in elements for
> your own custom protocols.
>

and from Peter:

 > You of course know that this leaves all the other SPs and applicatons
 > the user's browser has sessions with untouched and hence vulnerable,
 > by creating a false sense of security ("I did logout, so I'm good").

Yes, I think the Shib team has done a good job of describing why its 
unlikely that clicking Logout on some site will actually log me out of 
all the services that I've previously visited. There's too many moving 
parts, too many dependencies on external parties and implementations.

But -- that said -- a growing number of campuses are looking to take 
some initial steps. The first step for many campuses seems to be to 
implement a logout endpoint at the IDP that destroys the IDPs session 
cookies. When a user is redirected to this endpoint, some sites let the 
user decide whether to destroy the session; other sites just destroy the 
session.

This implementation clearly is NOT the full Logout of all SPs. But, the 
thinking is that it does provide some value.

So, reading Scott's thoughts at the top of this note -- would this be a 
different profile? Or is this approach "close enough" to the original 
intent that the standard values could be used ?