*MACE-WebISO Conference Call*
November 27, 2001

*Participants*

Nathan Dors -- Washington(chair)
Scott Cantor -- OSU
Steven Carmody -- Brown
Jeff Eaton -- CMU
Steve Willey -- Washington
Bob Morgan -- Washington
Ryan Muldoon -- Wisconsin
Scott Fullerton -- Wisconsin
Russell Yount -- CMU
Nate Klingenstein -- Internet2(scribe)

*Discussion*

Version Tracking

        The University of Washington has determined that it would like to
maintain the Pubcookie CVS repository, but there's still discussion about
the composition of an initial core team. The need for CVS is growing
increasingly pressing, however, as, for example, there have been changes
both by Carnegie Mellon and Washington to the login CGI, which is now out
of synch.

Logouts

        The Pubcookie team has sent out a near-term logout solution pending
further discussion of constructs such as application domain logouts and
logouts of all Pubcookie-using applications at once.  They have also been
working through the ISAPI filter problems to find out why it has been
failing in all external implementations.  Nathan stressed that the next
major milestone is to get a good code development environment, figure out
the filter difficulties, and start working forward from there.
        Steven reported that Meteor is involved in extensive work on
managing different levels of authentication -- that is, trying to build a
trust network where the requirements for authentication vary by site.
There is work for development of a set of protocols and other necessities
along the way to support the idea of upgrading authentication mid-stream.
It is unclear whether the group wants to work on designing this ability
into an ISO system immediately, which seemed like a fair deal of challenge.
The conclusion is that this is an interesting and important scenario to
keep on the issues list, but something which will not be solved in the
near-term.  Trying to support a business model for complicated multi-party
security using the generic underlying technologies is extremely difficult.

Pubcookie/Application Communication

        There was a thread on the Shibboleth Design mailing list with an
extended discussion about exactly what a relying application would be able
to know or would need to know from the WebISO system.  One of the things
especially important to Shibboleth itself is login session timing
information, which would be used in the formulation of attribute
assertions.  The time when the assertion expires is something that
Pubcookie doesn't yet hand to the application.  Bob called communications
between the ISO system and the applications relying on it an "untapped
area" waiting to be developed.  There was also a suggestion that it would
be a good eventual goal to split a WebISO system into session management
and identification libraries.

Further WebISO Requirements Review

        The group proceeded to work further through the WebISO requirements
draft put out by Ryan, looking now at the recommendations section of the
document.  In element 6 of the recommendations, there's a list of several
name-value Pubcookie attributes.  An attempt to elaborate generally on what
these attributes were supposed to encompass in terms of the information a
WebISO should pass to relying applications rather than a list of the
specific attributes was preferred.  The group wanted to be able to nail
down a general prefix for the sake of interoperability.  The group
considered briefly using SAML as a starting point, as it's one of the only
standards in the world currently addressing this functionality.  Bob was
worried, however, stating that "the complexities of XML are certainly
non-trivial" and that the benefits might not be greater than the present
difficulties.
        Requirements placed on clients in a WebISO system were not
discussed in the current draft of the requirements document, but they were
recommended as an important addition.  Currently, Pubcookie doesn't think
beyond the standard Mozilla/IE model, but there's value in eventually
considering the broader concept of a browser.  Some of the more explicit
requirements, e.g. SSL or redirections, could be noted.