*MACE-WebISO Conference Call*
February 4, 2003

*Participants*

Nathan Dors -- Washington(chair)
Scott Fullerton -- Wisconsin
Robert Knight -- Princeton
Karsten Huneycutt -- Duke
Bob Morgan -- Washington
Todd Piket -- Michigan
Nate Klingenstein -- Internet2(scribe)

*Discussion*

Anonymity & Kiosks

	The group once again revisited the concepts surrounding kiosks, 
this time in a different light, considering the idea of location-based 
policies.  "Even in a bright future world," Bob reasoned, there will 
still be a need for some sort of method to acquire the user's location 
as a context.  There is no other viable way to capture the scenario of a 
user going to the library, accessing materials available only from the 
library, checking personal mail, and leaving the library where access 
privileges are revoked.
	The problem may be seen as being composed of separately assigning a 
set of rights and privileges based on location which are checked and 
revoked appropriately, and unifying these rights with the user's 
existing rights and identity.  While there is a variety of methods by 
which this could be implemented, nobody on the call was aware of any 
authentication system that was able to perform this sort of union.

API Review

	Karsten wondered why the protocol described by Larry Greenfield of 
CMU would allow query_submit to return an incomplete answer.  His view 
was that, rather than returning an incomplete answer, returning nothing 
and redirecting if the answer weren't complete would be preferable.  He 
reasoned that the application is already comfortable with the WebISO 
layer doing "things it may not completely always know about."  The group 
couldn't completely determine what was implied by the text, nor what the 
system would be at which this took place, and agreed some clarification 
could be useful.
	Given that part of the intent of writing the document is to reduce 
the WebISO system to its absolute minimum functionality, this may not be 
the best place to call out available options.  There is also a spectrum 
between a WebISO API which is very comprehensive, and likely easier to 
integrate with WebISO systems, and a less comprehensive API which would 
be easier for applications to utilize.  Saying that the rest of the 
environment is responsible for communication with the browser is true 
for some designs and removes some of the requirement on the WebISO 
system, so Bob felt it appropriate to define the API such that there is 
no assumption of that ability by the WebISO.  However, later in the 
call, it was also discussed that breaking this API into multiple 
profiles with scaling levels of complexity would be useful.
	Bob opined that task would then be to design an Apache module that 
would be able to interface with applications in certain ways with 
certain header variables and handle WebISO functionality in a fixed 
way.  The current document instead describes an API that can sit between 
any WebISO system and any application, which Bob felt amounts to too 
many variables to lump into one cohesive solution.

Windows & WebISO

	Stemming out of a discussion on an e-mail from Steven Carmody of 
Brown University, Bob reflected that one of the things a traditional 
Windows & Kerberos environment didn't usually attempt to deal with is 
application-initiated login of users.  It is also unclear how a WebISO 
authentication would relate to a Windows-native authentication, and 
whether these authentications would have different domains or contexts 
in which they were valid.
	Windows-based applications can make the assumption that there is 
always an authenticated userID, because they will never be invoked 
except in that environment.  In other cases, applications must be more 
sophisticated because they must be able to acquire authentication 
contexts themselves.  This makes API calls more difficult and complex 
for applications, and complicates some functionalities for the WebISO 
system.