*Action Items*

New
[AI] {Group} will continue developing documentation for proposed approaches for middleware-enabling MLMs.
[AI] {Jill} will send the MList wiki operating instructions to the group via the list.
[AI] {Jill} will evaluate the SIP.edu architecture to understand its use of the authoritative email address attribute.
[AI] {John-Paul} will repair the error message on the wiki.

Carry Over
[AI] {Jill, Darrell and John-Paul} will summarize middleware integration points and other discussion points for Mailman conversation.
[AI] {Jim} will spearhead the group’s development of the common taxonomy of terms and send it to the list for group participation in its development.
[AI] {Paul, Serge and Olivier} will develop a list of generic topics addressing spam and mailing list management software.
[AI] {Jill} will notify EDUCAUSE of Mailing List survey results to be placed in the EDUCAUSE library.
[AI] {Jim} will incorporate Sympa developers’ comments into the WG’s models.
[AI] {Jim and John-Paul} will discuss local-interface preference storing of attributes. And, will send a brief summary of the discussion to the WG via the list.
[AI] {SteveO and Jill} will gain a better understanding of Sympa documentation and translation requests and coordinate follow up w/ Renee and Jill.
[AI] {Jill} will develop VO survey distribution list, and will follow up with NSF and DOE for possible VO survey candidates.

*Attendees*
Jill Gemmill, University of Alabama at Birmingham (Chair)
John-Paul Robinson, University of Alabama at Birmingham
Paul Russell, University of Notre Dame
Terrie Clark, Internet2
Lisa Hogeboom, Internet2
Steve Olshansky, Internet2

*Discussion*

The group discussed using the WG’s documents to facilitate mailing list middleware integration discussions at the Mailman developers meeting on March 19, 2005. The Mailman developers can then provide comments to the direction of the WG’s documentation.

The group held a discussion testing assumptions around identity management and middleware-enabled mailing list software.

The WG’s diagram refers to an identity provider and outlines two outputs for authentication based on the unique identifier: Successful successful authentication or unsuccessful authentication. The unique identifier (email address or other) is actually an attribute and is not provided by an identity provider (IdP). Initially, the identity provider states asserts that the user has successfully authenticated. , Andand, that the identity (if provided) is a unique name and (though it may not necessarily be something useful to the application). Thus, applications using attributes released in this fashion require a unique persistent identity identifier to be stored in for use by the application. Associating an email address as the identity of the user presents middleware integration challenges that will be identified in the WG’s documentation.

Do mailing list systems environments perceive utilize identity as an integral component of authorization? The WG documentation will reflect the general purpose cases, addressing the used use of an email address as a unique identifier and an attribute based approach. Many subscribers’ identity is an email address or set variation thereof because the authentication/authorization process sends and receives messages with this as the default. In addition a mailing list distribution point cannot identify a user without an email address where mail can be received. Most mailing list software applications are structured to process emails sent from users that require no verification beyond membership in this group (list subscribers).

If operating in a Shibboleth-type environment with an identity provider, Sympa assumes that the ID is authoritative for a particular email address. Currently this is not an issue in Europe, but it is possible in the near future that one user will have multiple email addresses generated from multiple systems and would like to the flexibility to use each email address for different lists hosted by one MLM as needed.

One way to separate identity from an email address is the use a separate identity provider for each email address. For example, an individual might have more than one email address generated by independent identity providers like sam@rice.edu and sam@particlalabrice.edu sam@particlelab.rice.edu. This will likely apply to VO’s and will be considered by the WG.

The group will hold a track session at the Interent2 Internet2 Spring Member Meeting in AprilMay. The group will use this time to report mailing list survey results and discuss spam and mailing lists. For more information please see: http://events.internet2.edu/2005/spring-mm/

The next call is Wednesday, March 16, 2005 at 12:00PM ET. The call in number will be distributed with the agenda prior to the call.