*MACE-WebISO Conference Call*
March 5, 2002

*Participants*

Nathan Dors -- Washington(chair)
James Blair -- NCSU
Scott Cantor -- OSU
Tom Dopirak -- CMU
Jeff Eaton -- CMU
Michael Gettes -- Georgetown
Larry Greenfield -- CMU
Lisa Hogeboom -- Internet2
Dan Jones -- Colorado
Jon Minor -- CMU
Bob Morgan -- Washington
Tom Jordan -- CMU
Linda Pruss -- Wisconsin
Nate Klingenstein -- Internet2(scribe)

*Discussion*

Code Merging

        Two significant changes to Pubcookie remain, as yet, to be unified
with the main distribution source code.  Larry has worked extensively on a
back-end authentication model for Pubcookie, and Washington has made
numerous enhancements regarding how logouts should be handled.  CMU is not
yet running these backend enhancements in active implementational models.
Nathan expressed his optimism that the two code bases could be relatively
rapidly merged, citing Mozilla's CVS service as an example of a set of
diverse modifications which can be quickly unified. 

Levels of Assurance

        A common theme in the PKI world is that of levels of assurance.  
These address the various amounts of confidence relying parties may have
in the fact that the presenter of a given set of credentials is indeed the
subject of the credentials.  This ability could be important for WebISO
projects, giving a way for users to authenticate with a given level of
assurance to gain access to different services.  It would also allow an
institution to use multiple authentication methods with a WebISO system
and specify different applications and abilities accessible based on these
methods.
        There is an added level of complexity in the WebISO model,
however, where applications may desire the ability to request a given
level of assurance.  One of the things most sites will need is a number of
hooks to plug-in various authentication methods with a standard interface,
such as Kerberos, LDAP, and others.  Standardizing the levels of assurance
granted by these different forms of authentication is relatively
difficult, however, with a number of local factors contributing
signficantly.
        This would require a significant new level of sophistication in
the client Pubcookie applications.  The group expressed a desire to allow
applications to request levels of authentication rather than requesting
forms of authentication, requiring the main Pubcookie server to be capable
of this mapping.  While it is relatively obvious in the few use cases
currently implemented -- SecureID vs. NetID for the University of
Washington, for exmaple -- this is still a useful ability.  Bob has
started a writeup along these lines.

Multiple Realms

        Some campuses have multiple authentication realms, necessitating
different logins or ID's with different permissions based on which realm a
given principal authenticates from.  A specific application may choose to
authenticate differently or give different permissions depending on what
sort of ID it is given or which realm the ID is located within.  However,
many current applications may be unprepared to accept ID's with varied
levels of permissions or with an appended realm.
        The traditional way to express multiple domains in a userID is to
phrase it as user@realm.  The group mentioned that Shibbolized
applications will be given userID's in the form of user@realm frequently
and should therefore be prepared to handle the format.  With this
preparation, it would not be extreme to expect that they could eventually
handle similar user@realm attributes from the local WebISO service.  CMU
had many opinions about how this could be done in implementation, and Bob
extended the offer to them to elaborate further on several of these ideas.
        This allows the domain to make access decisions based on both the
userID and the realm, e.g. locking the entire CS department out of a given
service.  Alternatively, an intelligent application may realize it's been
given a CS-specific identifier and map it to a general campus identifier
while retaining credentials for the CS-specific identifier or acquiring a
new set of permissions.  These abilities would not constitute a part of
Pubcookie, but would instead be performed by applications themselves after
Pubcookie informed them of the current principal being used.
        One option for implementing user@realm in a backwards-compatible
fashion is to pass the user and realm individually as strings.  This would
leave @realm as more of a configurational option to universities so an
individual institution could decide its importance and whether to use the
attribute at all.  The group was more in favour of passing user@realm as a
string itself, so the Apache module would receive user@realm for
remote_user.