**MACE-Dir Call 18-May-2009**

**Attending**

Brendan Bellina, USC (chair)

Scott Cantor, The Ohio State U.

Paul Hill, MIT

Sandeep Sathyaprasad, NIH

Benn Oshrin, Rutgers

Etan Weintraub, Johns Hopkins

Steve Olshansky, Internet2 (scribe)

*Carryover 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

[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.

**Discussion**

1. Discussion of use cases for an external ID or protocol specific (OpenID, MSLiveID) identifiers to be added to eduPerson to assist schools integrating with external vendor services. [See MACE-Dir thread "Proposal of New Attribute"]

The driver is the desire to leverage external IDs as alternate credentials, enabling users to authenticate separately and have that identity tied to the user's main organizational identity.

Q: Would the LoA be lower for external authentication?

A: This would depend upon the initial authentication practices.

Expressing OpenIDs in SAML is being looked at by Scott and others in the SAML community, but how this will unfold is not yet clear. The external linking use case is different. If this attribute would be shared inter-institutionally, that might make a good case for incorporating it into eduPerson, but it was observed that reaching broad consensus on this may be a challenge.

Standardizing the syntax would be critical, as it will have significant impact on downstream code utilizing this attribute.

It was also noted that packing multiple protocols into a single attribute is likely not a viable approach, e.g. because their attributes could take different forms.

The potential for proliferation of protocols to be accommodated was discussed, and consensus was that this is unlikely to be a major issue given the barriers to success for new ones.

2. Overview of the OpenRegistry project - Benn Oshrin

See slides at:

- OpenDoc: <http://www.ja-sig.org/wiki/download/attachments/17006624/MACE-Dir+OpenRegistry+May+2009.odp?version=1>

- PDF: <http://www.ja-sig.org/wiki/download/attachments/17006624/MACE-Dir+OpenRegistry+May+2009.pdf?version=1>

Q: Re: the update queue and directory builder -- for institutions seeking to integrate this with their existing infrastructure, what about update types that don't lend themselves to a queue? E.g. a department code that an employee is assigned to, when the department name changes?

A: The intent is to have a set of dictionary tables, which could be provisioned by systems of record. When an authoritative source cannot be identified, the IT staff would need to maintain that dictionary themselves.

This topic will be revisited on a future call...

3. Next call Monday 1-June 4:30 PM EDT