[Sessions] Agreed points from 5/25 telecon

[Hal Lockhart <hal.lockhart@entegrity.com>]

Here is what I promised to write up from the meeting. I hope it is not too
terse. If it is not clear, please ask.

Terminology:

timeout = idle timeout. Under SAML, all assertions become invalid when their
validity period ends. This is called expiration.

In the question of multiple timeout values:

Only one global timeout value will be implemented. No means will be provided
to discover whether the user has been idle over the ecosystem for some other
amount of time.

Session participants can maintain local timeouts which differ from the
global value. These will be determined only by local activity and produce
only local logout.

If the local timeout is shorter than the global, then when a user times out
locally they are logged out locally. If the user returns before the global
timeout, they will presumably present a ticket and things will proceed just
as if the user had never been to that site before.

If the local timeout is longer, the participant site will simply ignore the
global logout and perform local timeout. Essentailly this is a variant on
ignoring the global logout and continuing until the assertions expire. 

Message Flows:

There are four operations supported:

1) Login, 2) User logout, 3) Admin Logout, 4)Timeout

Timeout has 2 phases: determination and execution.

For economy of design, timeout execution should work the same as user logout
and admin logout.

Agreed flows:

Login - user logs in at authentication authority/session authority, gets
ticket, user presents ticket to participant site, which pulls (req/resp)
authentication assertion from session authority, session authority adds
participant to list

User logout and Admin logout - logout performed at session authority -
session authority sends informational (oneway) message to participants in
list

Timeout execution phase - session authority sends informational message to
participants in list

FLow not agreed yet:

Timeout determination - could be done by having session authority pull touch
info from participants when needed or have participants push touch info on
schedule. Major properties seem to be granularity (how close to specified
time does timeout occur on average) and overhead (total messages sent). Not
clear how approaches compare with respect to the two properties. May depend
on assumptions about 1) number of participants total 2) number of
participants per user session 3) session length, 4) timeout interval and 5)
reporting interval (for push). Dave will work on this.

Hal