John, yes that does make sense.

As a result of today's telecon about reducing the scope of this item, I was considering the implications of session authorities not addressing idle timeout.

Givens: - We have service providers that have some sort of mandatory timeout restriction (preferably idle, but we don't have that today) - Service providers typically have need to create local sessions (either legacy or to streamline interaction)

Consideration: Multiple sessions without global idle timeout monitoring could be a reasonable compromise.

I still see need for some kind of independent management of sessions for collections of SPs, where each collection is made up of 1 or more SPs with similar security policy. Then if we could at least provide a mechanism for a service provider to signal a session termination or re-authentication required? The issue I have today is SPs that want to do some kind of timeout (or session logout) and force a re-authentication for their session only. Because we have an SSO implementation (single global session), a re-authentication event is handled automatically by the authentication authority without user interaction. The SP considers that a security flaw, potentially to the point that the SP will not participate in our enterprise SSO initiative. If the SP had a means to control "their" session, I could likely sell the compromise.

The clearly stated business scenario does call for global idle time tracking, but something is better than nothing.