*MACE-WebISO Conference Call*
September 3, 2002

*Participants*

Nathan Dors -- Washington(chair)
Steven Carmody -- Brown
Jeff Eaton -- CMU
Scott Fullerton -- Wisconsin
Larry Greenfield -- CMU
Chris Misra -- Massachusetts
Bob Morgan -- Washington
Todd Piket -- MTU
Steve Willey -- Washington
Nate Klingenstein -- Internet2(scribe)

*Discussion*

        Two new documents were circulated prior to the call.  Bob completed
his preliminary work on the definition of WebISO systems as a general set
of requirements, and Scott compiled a survey of existing systems with
functionality that is similar to that a WebISO provides.  The group
reasoned that working with these two documents in tandem and allowing them
to grow on each other's insights would be a natural way to evolve the model
and list of compliant and applicable systems.

WebISO Model

        Bob gave an overview of his goals and vision for the WebISO model.
The model is designed to derive something that is a fairly accurate
description of the current taxonomy of WebISO systems whose creators and
users are participating in the group.  Bob would then want to check
existing models against the document he's written to generally verify that
it covers them well.  In addition, it could suggest a functionality which a
WebISO system had not thought about implementing but which would be useful
to the designers of that system.  It could also have a functionality which
is fairly similar to one presently in the WebISO system, which would be
easily adopted and lead to some modest degree of eventual standardization.
As of yet, there is no architecture-specific language.
        A general observation Bob offered as a veteran of many
standards-writing processes is that it's extremely difficult to write a
normative MUST into requirements documents.  It's often unclear to readers
whether this MUST means a compliant system must support the functionality,
must implement the functionality and optionally use it, whether use of the
functionality is mandatory in addition to its implementation, etc.
Additionally, a set of requirements that is too strict could be difficult
to become compliant with, dissuading potential users of the standard.

Additions to the WebISO Model

        Steven wanted to add a requirement to WebISO systems that it isn't
necessary to go through the front door.  This differentiates a WebISO
system from some portals, which require that all interactions with the user
must be performed through interfaces provided by the portal.  In many
portal architectures, the general premise is that if authentication is
initially performed within the portal space, then all subsequent
communications will take place through channels established by the portal
or through the portal itself.  In a WebISO system, generally a session is
established with a login server which then places some sort of ticket or
cookie in the client.  Relying applications then verify the cookie with the
central login server to determine whether it is valid before granting
access.  The requirement Steven posited is not as much about portals as it
is about explicitly not requiring a three-tier architecture.
        Another comment was that the solution should generally provide the
enterprise some flexibility in choosing the actual authentication method.
Additionally, there should be some standard interface designed for
interoperating with the WebISO system.  While all known examples do this,
the group felt it worthwhile to call it out explicitly.
        A requirement Bob wrote that Steven felt was unusually strong was
that existing applications must be modified to work with existing WebISO
systems.  It's often needed and appropriate, but can depend on other
extenuating variables in specific implementations.  Bob agreed that this
could be softened somewhat, but wanted some degree of it to remain.

Usernames

        One feature which is of great potential benefit but which can prove
challenging to interoperability, especially with more lizard-brained
applications, is the use of indirect identifiers.  What may seem like the
most obvious way to send a user identity is using their userID.  There are
some significant potential privacy and flexibility benefits to using some
sort of more generic key which is then used to acquire more information,
such as userID.  For example, while "rlbob" might be typed into the
weblogin page, webapps would receive "x327b".
        Bob said that the University of Washington would consider that a
directory thing, not a WebISO thing, for the reason that "up to the
membrane" the application has a mechanism to acquire more information about
the user.  The webapp is likely to request or receive other information
anyway, so it's easy enough to provide this functionality.  Others might
decide that these identifiers are relatively well-known and the community
is fairly closed, so it's easier and not necessarily inappopriate anyway.
        A simple, clean solution that the University of British Colombia
has implemented is simply to make the userID as entered at the weblogin
page the same as the relatively decoupled userID that applications use to
get further information about the user.  Then, the system has the option of
using the entered ID as either the proper ID for the user or as a pseudonym
for the user which is then used to acquire more information.
        Several ways to write this into the document in a loose and
suggestive way were mentioned, but none was adopted.