Extracted ITML Session Management Use cases and requirements

["Orchard, David" <dorchard@jamcracker.com>]

Use Cases and Requirements

The following Use cases describe the interactions supported by this
specification.

1.a. Browser-based Single Sign-on to ecosystem
1.	A user logs on to Jamcracker.  
2.	The accesses a partner site that participates in the ITML session
management ecosystem.  The user is not prompted for an authentication
credential.  Authorization to resources is controlled by the partner.  This
use case may be described as centralized authentication and delegated
authorization.

1.b.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

1.c. Time-Out
1.	A user has abandoned their interactions with the ecosystem.  The
virtual session must be purged from all machines participating in the
ecosystem and the session.

1.d.Traversal to multiple partner sites
1.	A user may travel from Jamcracker to site A and Site B.  It is
imperative that the most recent access time of the ecosystem be the relevant
access time for purposes of timeout of the echosystem.


Requirements
1.	The session information shall map easily to web sessions.
2.	The algorithm must be robust in the case of failure of a
communication path or node
3.	The algorithm must allow for Partners to not notify in the case of
session update
4.	The algorithm must allow for failure of Partners
5.	The algorithm must work with version 4.0 + web browsers and wireless
devices
6.	A user timed-out from an ASP should be able to re-access the ASP
without prompt for username/password.


Assumptions
A primary assumption has been made:

1. "Users tend to interact frequently within an ASP and infrequently
interact across multiple ASPs".  

This assumption allows the use of a conversation between Jamcracker and an
partner when for purposes of timing out and logging out. 

2.	There is a prior existing trust relationship between Jamcracker and
the partner.
3.	The Content of the session is defined separately, such as S2ML.
4.	Offline support is not required.
5.	It is required that Jamcracker be informed of accesses to partner
systems for the purposes of billing, anonymity is a bug not a feature.
6.	Authorization information exchange is not required.
7.	Access to an ASP before access to Jamcracker is not required.  That
is, there is no requirement for complex redirecting from ASP to JC back to
ASP if correctly logged on.  Microsoft Passport, Netegrity Siteminder, etc.
provide this functionality and we are loath to re-create it.  

Dave Orchard
XML Architect
Jamcracker Inc.,    19000 Homestead Dr., Cupertino, CA 95014
p: 408.864.5118     m: 604.908.8425    f: 408.725.4310

Named to Red Herring's list of 100 Most Important Companies:
www.redherring.com/mag/issue79/herring100/jamcracker.html