MACE-Dir Call 2-June-2008

**Attending**
Brendan Bellina, USC (chair)
Etan Weintraub, Johns Hopkins U.
Debbie Bucci, NIH
Nate Klingenstein, Internet2
Tom Barton, U. Chicago
Steve Olshansky, Internet2 (scribe)

**New Action Items**

[AI] (Debbie Bucci) as part of NIH's engagement with InCommon, will follow up with InCommon participants as follows: 1) give a one or two sentence *why* NIH wants/needs/requires each attribute 2) post this and the link to the namespace to the InCommon-NIH wiki space and 3) announce to InCommon-NIH list when posted.

*Carryover Action Items*
[AI] (SteveO) will add named anchors to the published eduPerson spec to make navigation easier.

[AI] (RL "Bob") will announce eduPersonAssurance on the TF-EMC2 list

[AI] {Bill Weems} will share a whitepaper addressing global Identity Management.

[AI] {Tim Crouch} Craft a survey on eduCourse adoption and usage.

[AI] {Bob Morgan} will craft a survey on use of the mail attribute and possible need for additional email attributes.

**Discussion**

*NIH LOA1 Attributes Discussion*

The call was joined by Debbie Bucci, the SSO Program Manager at the Center for Information Technology of the U.S. National Institutes of Health (NIH), discussing their participation in the InCommon federation and the attributes they are anticipating for their initial LOA1 applications.

Following up on initial work done with the University of Wisconsin and Johns Hopkins they are expecting attributes that communicate first name, last name, email address, an identifier such as ePPN or ePTargetedID, and something indicating the organization. Some possible directory attributes to communicate organization include: eduPersonOrgDN, eduPersonOrgUnitDN, eduPersonPrimaryOrgUnitDN, departmentNumber, organization (o), and the eduOrg attributes. In addition attributes like ePPN and eduPersonScopedAffiliation that include a scope could be parsed, although that is not something they would like to have to do at the applications.

NIH's short-term goal is to enable 12-15 LOA1 applications related to grants. An important aspect of this is being able to distinguish affiliation for the purpose of AuthZ decisions at a more granular level than simply "institution."

Current practice for institutions with NIH grants is just to assert institution. NIH internal reporting breaks it down further (e.g. Med School).

For the sake of simplicity a common profile that everyone implements would be best, for obvious reasons. In the near term this would be a SAML attribute defined by NIH for their purposes, which is populated by institutions as they wish.

There was a wide ranging discussion of various eduPerson attributes and how they are populated in current practice, in the context of how they might be useful to NIH.
http://www.educause.edu/eduperson/

FirstName LastName are needed for display purposes, which is a common requirement. displayName (defined in RFC2798, inetOrgPerson) is commonly used for this purpose, and would seem appropriate here.

Consensus was that NIH should tell institutions what data it needs for a user's name, how it intends to use it, and let institutions determine how to meet that need - common name, given name, surname, business e-mail.

Discussion then proceeded to the applicability of eduPersonOrgDN, eduPersonOrgUnitDN, eduPersonPrimaryOrgUnitDN, departmentNumber, organization (o), and the eduOrg attributes

It was proposed that instead of OID, NIH ought to define a URL in their namespace for an NIH-specific attribute (e.g. http://nih.gov/attributes/attribute_name), which could later be used to provide information about populating that attribute. If NIH does this, it can define for itself the data it expects to receive, and the ways in which it will be used.

It was noted that users often interact with NIH with multiple affiliations, and from different IdPs, that NIH needs to connect to recognize the user.

For specific requirements, NIH should state that it requires IdPs to assert certain attribute(s) with expected semantics…

eduPersonPrincipalName (EPPN - defined in eduPerson 1.0) will be used for now by NIH as the unique identifier, in the interest of expedience, even though it is understood that it may be reused and that a user's EPPN can change over time. eduPersonTargetedID (EPTID - defined in eduPerson 200312) was discussed, but since it is not universally supported it doesn't seem to be a good choice for exclusive use for now. It was proposed that NIH accept either one, but if an IdP chooses to use EPTID, it must be prepared to guarantee that it will send the same EPTID to the NIH set of applications, even though they are different SPs.

*Discussion of possible benefits in restructuring eduPerson document* somewhat along the lines being considered in Norway (see email: "Fwd: Editing eduPerson" sent to the MACE-Dir list May 29, 2008.

Separating SAML-specific components from LDAP-specific components would be the goal. It was proposed that this ought to be viewed in the context of a broader discussion toward a cohesive strategy for presenting common information to applications to meet their respective needs. This could include developing a UML model for eduPerson, and/or developing a means of fleshing out the relationship of eduPerson to other schema in use by applications.

Activities (future work) resulting would be:
1) generalize the eduPerson spec to remove references to specific protocols and storage mechanisms, to make it instead a generalized data model for how to store information about users in an educational setting.
2) develop a good way to answer the question "what attribute name should I be using to assert [data]"?