*MACE-WebISO Conference Call*
December 3, 2002

*Participants*

Steven Carmody -- Brown
Nathan Dors -- Washington(chair)
Jeff Eaton -- CMU
Larry Greenfield -- CMU
Jim Farmer -- JA-SIG
Bruce Jolliffe -- UBC
Robert Knight -- Princeton
Bob Morgan -- Washington
David Walker -- UCOP
Steve Willey -- Washington

*Action Items*

1.  Larry will post a draft API to the mailing list, covering target
application interaction with WebISO agents.

2.  Scott will encourage OKI to post a better sample application.

3.  Bob will ensure that someone from Shibboleth fills out the WebISO
questionnaire.

*Discussion*

Highlights from the IETF Meeting in Atlanta

	Bob, Larry, and Derek Atkins (loosely associated with MIT) took
some time in Atlanta to discuss target application APIs, both in the
WebISO and Shibboleth spaces.
	Derrick (who's helping develop Shibboleth target-side components)
has been working on a proposal for delivering data to target applications.
A set of "core library" services might be defined, encapsulating such
things as initiating handle acquisition, retrieving attributes, etc. The
0.7 release just saw the light of day, so this proposal will be used to
shape and formalize the interface provided in future releases.
	Larry is working on a similar draft document for the WebISO realm,
again focused on target-side integration between applications and agents
of WebISO functionality. (WebISO and Shibboleth are tracking each other in
this general "API" area.) He envisions something fairly minimal and hopes
to find nice ground where WebISO modules and code libraries overlap.
        On a side note, Bob mentioned IETF discussions struggling with how
to augment HTTP/WebDAV protocols to define common methods of
authorization. The proposals are byzantine; it may take a while for a RFC
to coalesce.

OKI Conversations

	Scott (serving as primary liaison between the WebISO working group
and the Open Knowledge Initiative (OKI) project) fielded questions
regarding the OKI specifications and motivations.
	Bob: Is this OKI stuff focused, as WebISO is, on a Web-specific
domain? Answer: No, it's attempting to be more broadly encompassing than
that, more flexible, so as to allow OKI services in all sorts of contexts,
using all kinds of protocols, to bind to underlying authentication and
authorization services.
	Someone: How does OKI make the distinction, which is often very
real in the way these WebISO systems work in practice, between setup- or
configuration-time settings and run-time interactions? Do OKI services
need to be written with specific knowledge of the underlying AA services?
Answer: good question. At least in the Web/WebISO domain, these issues
might be better brought to light with a somewhat more real-world sample
OKI application. How would it bind to a possible WebISO API? How easily
could it be moved between, say, a Pubcookie, or a Yale/CAS, or another
extant WebISO implementation, with or without a WebISO API.
	Scott (an aside): the OKI authorization spec has been criticized
by some for being too little, and criticized by others for being too much.
It either assumes too much central control and doesn't reach far enough,
or it obscures the simple need for user attributes with a bunch of extra
complexity. Just goes to show you can't make everyone happy all the time.
	It is hoped that Chuck Shubert and/or Scott Thorn from the OKI
project can join us for future conversations about WebISO and OKI APIs.

TERENA/TF-AACE and GNOMIS Workshops

	Not a lot of time was left to report on what's going on across the
big bond, where Nathan recently attended a couple of workshops in Sweden.
First, a TERENA/TF-AACE [1] workshop, which is a pan-European task force
working on authentication and authorization problems. Then a GNOMIS [2]
workshop, which had a similar scope but with a more limited audience, as
evident in the "Greater Nordic Middleware Symposium" name. (Any land once
attacked by the Vikings is welcome, they said.)
	The WebISO landscape consists of various existing solutions - some
more WebISO-like than others - like Athens (UK), PAPI (Spain), A-select
(Holland). Others are designing new systems from scratch, e.g. FEIDE
(Norway). Packages from the states, such as Yale/CAS and Pubcookie, are
also being used and/or evaluated. But there's still the sense, as there is
over here, that local requirements (campus, country, or greater European)
as well as culture, laws ("directives"), and even personalities have an
overarching influence on technology directions. The idea of creating a
WebISO API for target applications was well received, but perhaps not with
the alacrity of people working a lot with external content providers and
commercial vendors. Tough to say.
	But one thing is clear, Shibboleth/SAML has everyone's attention
and its influence is apparent in a lot of the current and planned
activities.

[1] http://www.terena.nl/tech/task-forces/tf-aace/

[2] http://www.uninett.no/arrangement/gnomis/


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

    http://archives.internet2.edu/

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