*MACE-WebISO Conference Call*
August 6, 2002

*Participants*

Nathan Dors -- Washington(chair)
Brandon Blank -- Kansas
Tom Dopirak -- CMU
Jeff Eaton -- CMU
Daniel Fischer -- Virginia Tech
Scott Fullerton -- Wisconsin
Larry Greenfield -- CMU
Chad La Joie -- Virginia Tech
Bob Morgan -- Washington
Ryan Muldoon -- Wisconsin
Todd Piket -- MTU
Steve Willey -- Washington
Nate Klingenstein -- Internet2(scribe)

*Discussion*

Advanced CAMP Summary

        The general sense from the participants of the Advanced CAMP hosted
in Boulder by Internet2 was that the greatest usefulness emerged from a
session presented by Scott Cantor of OSU.  In light of many institutions
stating a desire to use Shibboleth in an intra-realm use case, Scott
compared and contrasted Shibboleth and WebISO.  There are many ways in
which Shibboleth can build upon and utilize a web-based, persistent
authentication scheme, but also ways in which it somewhat duplicates the
capability of providing this SSO information to relying applications.  If
there is eventually a SAML-based version of Pubcookie, it is likely that it
would draw on OpenSAML and perhaps other Shibboleth code.  In an eventual,
long-term view, Shibboleth in an intra-realm case would at least need a
sign-on system, meaning something may eventually be chosen as the default
sign-on system for intra-realm Shibboleth deployments, although this would
remain extremely modular and architecturally distinct.  However, Shibboleth
is not yet even in beta, and it is a relatively long-term solution.  It was
Larry's sense that, while Shibboleth is wonderful in the inter-realm case,
WebISO still has a definite and useful short- to mid-term place in
intra-realm implementations.
        Shorter-term and more theoretical discussion of the three-tier
problem was intended to be a major theme of the conference, but few new
themes emerged.  Amidst the lack of revelation was a general sense that any
sort of broader solution would need to include SAML and presumably coexist
well with Shibboleth.  Usability issues surrounding the use of HTTP POST
were briefly discussed, with users inevitably breaking the system by
slamming the "submit" button, as well as other design difficulties.  While
these present little architectural difficulty, the existing Shibboleth code
base has been modified to accommodate these user-introduced challenges and
they should be considered in future design, especially in terms of POST.

Standardized -- What?

        One of the themes that has arisen on the WebISO mailing list
recently is that of standardization of something to provide a more unified
approach to the ISO problem, of use both to users and especially
application designers.  The biggest issue that would face the group if it
tried to take on the problem of standardization in the WebISO space would
be the level(s) at which to define a WebISO system.
        A common application API that most WebISO systems would be expected
to implement could be designed.  Bob, however, informed the group that the
history of this sort of API "is grim."  While Java has created a large pile
of API's and Windows includes a large bundle of API's, these have all been
created from the point of view of an integrated, centrally-designed system.
Bob advised the group to pick its battles carefully, and that the goal is
both to nudge existing WebISO standards towards some sort of standard and
nudge vendors to utilize it.
        Another level of standardization would be to utilize a standard
payload for communication between applications and the central WebISO
service.  This would be of relatively limited utility to the applications
since it would specify only the formats which the applications should
speak, and nothing of the information that might be received, but this
would still be a significant step forward and may be much more realistic.
        An even more basic level of standardization is that which has been
looked at by WS-Security, which is specifically oriented towards securing a
SOAP environment to begin to support web services on top of it.  Using this
sort of infrastructure could eventually lead to a quasi-SSO environment,
although the group was unclear what this might look like, overall.
        As the most viable means of assessing the reasonable pathways to
approach the problem, the group wanted to census the currently available
WebISO systems to begin to scope the approach of the WebISO group.  [AI]
Scott offered to coordinate the effort to gather the list of existing
WebISO solutions to begin to look at what the MACE-WebISO group should
begin to standardize.

*Action Items*

1.  Scott offered to coordinate the effort to gather the list of existing
WebISO solutions to begin to look at what the MACE-WebISO group should
begin to standardize.


-----------------------------------------------------------mace-webiso-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

-----------------------------------------------------------mace-webiso--