**MACE-Dir Call 5-December-2011**

**Attending**
Keith Hazelton, U. Wisconsin-Madison (co-chair)
David Bantz, U. Alaska
Todd Piket, MNSCU
Tom Barton, U. Chicago
Michael Pelikan, Penn State
Mark Jones, UT-Houston
Scott Cantor, The Ohio State U.
Benn Oshrin, Internet2
Nate Klingenstein, Internet2
Steve Olshansky, Internet2 (scribe)

**Next call: Monday 19-December-2011 3:00 PM EST (UTC-5)

**New Action Items**
[AI] (All) review the proposed revisions to eduPersonAffiliation and discuss on the list.

[AI] (MichaelP and Keith) will be prepared on the next call to discuss eduCourse next steps.

**Carryover Action Items**
[AI] (Keith) will propose a discussion-starter on the subject of whether there should be MACE-Dir attribute specifications for Grouper objects: Role, Privilege, Subject, (others).
[AI] (RL "Bob") will distribute information about the UW person registry web service.
[AI] (Keith) will draft a problem statement on person and organization identifiers from social IdPs related to VOs, as a discussion starter, and will refer to IPEDS for reference.
[AI] (Keith) will edit the previous versions of the SAML Attribute Profiles documents to note that they have been superseded by a newer version.

**Discussion**

1. eduPersonAffiliation "Member" and other values: Proposed changes

"
2.2.1. eduPersonAffiliation (defined in eduPerson 1.0); OID: 1.3.6.1.4.1.5923.1.1.1.1

RFC 4512 definition
( 1.3.6.1.4.1.5923.1.1.1.1
NAME 'eduPersonAffiliation'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
Application utility class: standard; # of values: multi

Definition

Specifies the person's relationship(s) to the institution in broad categories such as student, faculty, staff, alum, etc. (See controlled vocabulary).

Permissible values

faculty, student, staff, alum, member, affiliate, employee, library-walk-in

Notes
If there is a value in eduPersonPrimaryAffiliation, that value MUST be asserted here as well.
The list of allowed values in the current version of the object class is CERTAINLY incomplete. We felt that any additional values should come out of discussions with the stakeholder communities. Any agreed-upon additional values will be included as part of the later versions of eduPerson.

"Member" is intended to include faculty, staff, student, and other persons with a basic set of privileges that go with membership in the university community (e.g., they are given institutional calendar privileges, library privileges and/or vpn accounts). It could be glossed as "member in good standing of the university community."

The "member" affiliation MUST be asserted for people carrying one or more of the following affiliations:
- faculty or
- staff or
- student or
- employee or
- other individuals (if any) to whom are granted the same institutional privileges that are afforded to faculty, staff and students.

Note: Holders of the affiliation "alum" are not typically "members" since they are NOT eligible for the full set of institutional privileges enjoyed by faculty, staff and students.

The "affiliate" value for eduPersonAffiliation indicates that the holder has some definable affiliation to the university NOT captured by any of faculty, staff, student, employee, alum and/or member. Typical examples might include event volunteers, parents of students, guests and external auditors. There are likely to be widely varying definitions of "affiliate" across institutions. Given that, "affiliate" is of dubious value in federated, inter-institutional use cases.

For the sake of completeness, if for some reason the institution carries digital identity information for people with whom it has no affiliation according to the above definitions, no eduPersonAffiliation should be asserted for those individuals.

"Library-walk-in:" This term was created to cover the case where physical presence in a library facility grants someone access to electronic resources typically licensed for faculty, staff and students. In recent years the library walk-in provision has been extended to cover other cases such as library users on the campus network, or those using on-campus workstations. Licensed resource providers have often been willing to interpret their contracts with licensees to accept this broader definition of "library-walk-in," though specific terms may vary.

The presence of other affiliation values neither implies nor precludes the affiliation "library-walk-in."
It is not feasible to attempt to reach broad-scale, precise and binding inter-institutional definitions of affiliations such as faculty and students. Organizations have a variety of business practices and institutional specific uses of common terms. Therefore each institution will decide the criteria for membership in each affiliation classification.

What is desirable is that a reasonable person should find an institution's use of the affiliation commonsensical.
"

Suggestions:
- remove "- other individuals (if any) to whom are granted the same institutional privileges that are afforded to faculty, staff and students." from MUST, rather something like *member may also be asserted...*

- replace "commonsensical" with something like "reasonable" or "plausible"

- There is some sentiment that use of this attribute is problematic for some, and it is better to use entitlement instead...

- The process for assigning these values is not specified e.g. in the InCommon POP, which probably would be a good thing to correct.

- Simply referencing the eduPerson schema is not really helpful for app developers to answer questions. The MACE-FedApp space would be a good home for useful guidance:
https://spaces.internet2.edu/display/fedapp/Home

2. Expanded IMS roles vocabulary and eduCourse revisions
- For revised role vocabulary, see Appendix B of
http://www.imsglobal.org/lis/lisv2p0pd/MMSinfoModelv2p0pd.html
- See also the full document set drafts of version 2.0 of Learning Information Services:
http://www.imsglobal.org/lis/index.html

It would seem useful for eduCourse to support these roles in the vocabulary.

Q: Are sub-roles intended as finer-grained values for roles, or it this a 2-part structure?
A: This would seem to be a 2-part structure.

Are there practices in use in the wild that can't be described in the eduCourse model? Are there ways in which it could be improved? It would be useful to get a better handle on this. This will be discussed on the MACE-Dir list, and anyone interested is encouraged to participate.

[AI] (MichaelP and Keith) will be prepared on the next call to discuss eduCourse next steps.

3. Kantara Attribute Management Discussion Group: Identifying high priority needs around attribute definition, management & sharing
- http://kantarainitiative.org/wordpress/tag/amdg/

Anyone interested is encouraged to suggest areas in which broad stakeholder community investigation and recommendations would be useful.

A current topic of interest is attribute aggregation. A refined problem statement would be a useful step forward. COmanage is tackling this for VOs, as is the InCommon Admissions project: https://spaces.internet2.edu/display/InCAdmissions/Home

For the Admissions project, consensus is forming around a central IdP for students to use in the undergraduate application process, and there is potential for using this later as a general-purpose credential for other higher-ed apps. Flow diagrams are currently being developed. The quality of identity-vetting is something of particular interest. De-provisioning is another issue to be addressed, of significant interest to the stakeholders. InCommon and PESC are the primary sponsoring organizations. There are currently 3 subgroups: technical (usecases and flows, and later wireframes), education (higher ed leaders), and business (making this financially viable and widely deployed).

Is there a role for MACE-Dir WRT attribute aggregation or the Admissions project? Attribute aggregation is currently tied to specific implementations (Shib SP). Defining the referral attributes would be very useful.

It was noted that OAuth is also tackling similar issues, akin to the VO model, although the aggregate is not asserted to a 3rd party. Cloud services will also be working on similar issues.