survey of session definitions + some comments

["Mishra, Prateek" <pmishra@netegrity.com>]

[Daren Platt]
session management as the transfer of end-user 
sessions between federated web domains.

logout - 
particularly the ability to notify partner/federated domains of a user's 
 explicit logout

[David Orchard - ITML]
"timeout", "relevant access time" -- several
time related attributes are part
of a session and may need to be communicated from one
actor to another

.Log-off 
 1.      A user has signed on to Jamcracker.  They can choose to log out of 
 the entire ecosystem from the Jamcracker portal.  They can also choose to 
 log out of a particular partner from the partner site 

[Tim Moses]
A Principal has conducted a session with Application A.  There is an
accumulated state
 associated with that session, and this is to be transferred to Application
B (presumably state
 accumulated in Application A is meaningful to Application B).

 The state is not a property solely of the Principal, so a name assertion or
entitlement assertion is
 not entirely appropriate

[Bob Blakley]
 (2) (a) The asserting party can explicitly create a session to which 
 the assertion is bound (using some facility we 
           define which enables the creation of a protocol-independent 
 notion of session which can be imbedded 
           in protocols as part of a binding specification), or

[Commentary - Prateek Mishra]
Bob Blakley is discussing the notion of developing a general session
definition within
OSSML and (IMHO quite appropriately) objecting to such a broadening of
scope.

Everyone else is actually discussing some meta-data associated with
an loosely defined concept called a session. Each security zone MAY
provide some notion of session based on proprietary technology, SSL or some
magic. 
We have only a sketchy idea what a session is (maybe in keeping with
tradition, we should call it foobar) except
that it may have a few standard attributes: start time, end time,
last access to resources, session name, session manager identity etc.
Typically, these attributes are not static but may be updated
in some unpredictable way based on user behavior within 
a security zone. 
 
It is useful to communicate
these attributes from one security zone to another. It is also
important to agree on a standard set of attributes and what
RPs should understand from them. I do not
agree with Tim Moses' thought that we need a new kind
of assertion: i see instead a need to perhaps define a few standard
elements that may be carried within a name or property assertion. But there
I am getting too far ahead...

Distributed logout is essentially a form of notification (explicit in
Daren's definition) between security domains. Maybe the simplest way to
go forward is to include a requirement for a notification
security service (I believe AuthXML has such a concept) and include
logout as a fully specified case (i.e., call out the required
elements to notify "logout").

- prateek mishra