MACE-Dir Call 26-Jan-2009

**MACE-Dir Call 26-Jan-2009**

**Attending**

Brendan Bellina, USC (chair)

Michael Wheeler, Pittsburg State U.

Scott Cantor, The Ohio State U.

Tom Scavo, NCSA

Tom Barton, U. Chicago

Victoriano Giralt, Universidad de Málaga (Spain)

Ken Klingenstein, Internet2

RL "Bob" Morgan, U. Washington

Ann West, Internet2

Steve Olshansky, Internet2 (scribe)

**Outstanding surveys**

Test Accounts survey: <http://www.surveymonkey.com/s.aspx?sm=SlFF6wbLYPXA7rZjaerpzA_3d_3d>

Group Usage survey: <http://spaces.internet2.edu/display/macedir/Survey+on+Group+Usage>

**New Action Items**

[AI] (Mike) review the LocalDomainPerson survey results and the Shibboleth attribute naming documentation with an eye toward useful attributes to generalize, as a reference for naming guidelines and base attributes to propose.

http://middleware.internet2.edu/dir/localsurvey.html

http://middleware.internet2.edu/dir/docs/internet2-mace-dir-localdomainperson-200505.html

https://spaces.internet2.edu/display/SHIB2/AttributeNaming

*Carryover Action Items*

[AI] (RL "Bob") will craft a survey on use of the mail attribute and possible need for additional email attributes.

[AI] (Brendan) will poll the mailing list for feedback on the use of name fields, and whether they have had the need to extend eduPerson locally with additional name fields.

[AI] (Brendan) will coordinate with the leaders of the Educause IdM Constituent Group, toward the goal of polling that group along with MACE-Dir for feedback on the use of commercial and open-source IdM products.

[AI] (Brendan) will work with SteveO to have eduPerson LDIFs updated on the web site

**Discussion**

1. (Michael Wheeler) Michael Wheeler, the Assistant Director of Systems and Networking at Pittsburg State University, discussed the potential uses and need for either expanding the eduPerson object class to include more academic information or creating a separate eduStudent object class for this purpose.

They have recently begun using directory services and Shibboleth, and created local attributes which could also potentially be used for inter-institutional sharing of resources. They see value in creating a new object class, containing a variety of attributes which more specifically describe a student's academic status and affiliations. Many of these could also extend beyond the institution, e.g. participation in athletic activities or fraternities/sororities, or delinquent account (and thus non-eligibility for services).

Q: are there current inter-institutional use cases, or is that application abstract and theoretical at this point.

A: the latter, at the moment, but presumably there are inter-institutional use cases which could be imagined...

Tom referenced the local domain survey Brendan led in the past, and the finding of the need for attributes related to courses (e.g. eduCourse), and European use cases different from ours in the US.

Scott noted a reference in the Shibboleth documentation on attribute naming:

https://spaces.internet2.edu/display/SHIB2/AttributeNaming

It was noted that these attributes could be created and utilized by a federation if required to support a particular use case(s).

Q: if these sorts of attributes were deemed to be useful for us to define, would they logically belong in eduPerson, or better kept separate in a new object class?

A: the logical first step would be the prior definition of use cases of foreseen common practice within US institutions, perhaps noting variations between large and small.

Since eduPerson's purpose is really to define standardized attributes to support the sharing of resources across institutions, and since these attributes being proposed would seem to be more internally focused, then if the forthcoming use cases support the definition of these new attributes their inclusion in a new object class would seem to be in order.

Victoriana noted similar use cases within Europe, e.g. for the mapping of grades and levels between countries.

Ken and Victoriano noted that in some cases, attribute discussions may not ultimately be best homed only within MACE-Dir or SCHAC (in Europe), but rather perhaps in some other forum which would cover us all. Also, some government agency notions of organizations or other related structures may vary from those of the higher-ed community, and to the extent that we want to define attributes that will work across these boundaries, we need to proceed with this in mind.

The question arose about guidelines for attribute naming conventions, and consensus on the call was that it would be useful for us to prepare a document to address this, at least in the form of recommendations if not mandates.

http://middleware.internet2.edu/dir/localsurvey.html

http://middleware.internet2.edu/dir/docs/internet2-mace-dir-localdomainperson-200505.html

https://spaces.internet2.edu/display/SHIB2/AttributeNaming

2. Attribute definition venues (formerly year of birth) discussion

Ken clarified that the issue is more about the right forum in which to hold these discussions, since attributes are used so heavily in the federation context. Is MACE-Dir the right venue, or should federations come together to form another venue for this purpose?

Ken cited examples in Denmark (date of birth, sourced from the school system and used for determination of service eligibility) and Australia (shared service token in a grid setting). The US government appears to be poised to move ahead with defining a piPerson (Principal Investigator) object class, with the InCommon Federation.

It would seem that there are multiple arenas that would be appropriate for specific attribute discussions, and flexibility is called for moving forward...

RL "Bob" noted that putting the genesis of attributes is similar to other standardization practices, i.e. a "bottom-up" process in which someone defines it and uses it, demonstrates that it works, others see its value and use it, then it becomes more formalized, and perhaps eventually winds up in an actual standardization process.

Thus it would seem appropriate for MACE-Dir to stay "on the sidelines" until attribute use cases are reasonably clearly defined and brought into this forum for formalization due to demonstrable campus need.

Liberty Alliance, OpenID, and OASIS were cited as examples of other organizations working on defining attributes in one form or another.

It was suggested that a periodic environmental scan would be useful in this context.

3. Next call: 4:30 PM EST (GMT-5) Monday 9-February-2009