*MACE-WebISO Conference Call*
November 13, 2001

*Participants*

Nathan Dors -- Washington(chair)
Steven Carmody -- Brown
Tom Dopirak -- CMU
Jeff Eaton -- CMU
Larry Greenfield -- CMU
Bruce Jolliffe -- UBC
Lisa Hogeboom -- Internet2
Ryan Muldoon -- Wisconsin
Russell Yount -- CMU
Nate Klingenstein -- Internet2(scribe)

*Discussion*

Logistics

        Bruce Jolliffe, a newcomer from the University of British Columbia,
is very interested in the WebISO work that is going on and is looking to
implement a campus-wide initial login through the website.  Nathan reminded
the group that all the requisite components are now available for download
directly from the Pubcookie website.  The ISAPI filter has not yet had a
successful installation outside of the University of Washington, however.
        There is going to be a developing need to create a Pubcookie CVS
relatively soon as groups proceed to make interesting modifications to the
code base.  Larry reported that he had already made several interesting
modifications to the code to make Pubcookie far more configurable during
runtime by increasing the modularity of the software.  There is always the
option of maintaining the CVS on Sourceforge, but they are at an
"interesting" juncture in their service at present, with many expressing
concerns over the future quality of service.  CMU offered their ability to
fairly easily bring up a bug-tracking and CVS service, which Nathan agreed
to keep in mind.  [AI] He also wanted to make an effort to check on local
CVS possibilities and report back to the group on what the best option
would be.

Review of the WebISO Requirements Document

        The group had a large number of small modifications to the wording
of the requirements, which will be reflected in the next version of the
document.  Application session and login session needed to be defined and
used separately to be more clear on which session is meant.  It also needs
to be explicit that these sessions refer only to those involving the WebISO
system, and applications must manage their own sessions for data other than
a user's identity.  Following are broader discussions of the few
contentious requirements which the group considered.  [AI] Ryan offered to
try to revise the document before the next call.

Requirement #1:  "Data format for session management" was unclear to
Nathan, but Ryan elucidated on the call that this was supposed to refer to
authentication session management objects with the goal of interoperability
and common formats for the various tokens passed around in a WebISO.

Requirements #2 & 3: Nathan suggested some clarification of the examples.
The login assertion is the reply from the login server to the target
webserver specifying who the user is.  More appropriate or illustrative
terms for the examples would be login session and application session.

Requirements #8 & 12:  There was a general support for an explicit logout
for the login session, but supporting a logout from all applications is
harder.  Zeroing out the session token won't necessarily handle these
logouts, and methods such as cycling through all applications and logging
out individually is difficult.  A savvy user at a kiosk can know the
applications visited and know to clear all application sessions and the
login session, but that's a stretch.  Replacing the login token with a kill
token which tells an application to logout is another strategy.  Still,
most of these are implementationally challenging, and there was a
suggestion to make #12 a requirement only for login.

Requirements #13 &14:  Steven was concerned that the fourteenth requirement
was essentially unbounded and served to potentially limit the effectiveness
of the WebISO to consolidate authentication.  The requirement means there
must either be multiple authentication mechanisms or one that can deal with
application communities, while removing multiple authentication mechanisms
is a stated goal of most WebISO systems.  Layering this is hard, and
codifying low, medium, and high would be even more difficult.  The group
thought that further discussion of zones was necessary before settling on
either requirement as a necessity.  While Ryan was happy to write up a
formal description of how he envisions the application community concept
working, it is unclear how this would fit with a requirements document.

*Action Items*

1.  Nathan will check on potential CVS services.

2.  Ryan will revise the WebISO Requirements Draft before the next call for
further discussion.