**MACE-Dir Call 30-May-2011**
**Attending**
Keith Hazelton, U. Wisconsin - Madison (co-chair)
Mark Scheible, MCNC
Scott Cantor, The Ohio State U.
Jim Leous, Penn State U.
Jim Green, Michigan State U.
Todd Piket, MNSCU
Steve Olshansky, Internet2 (scribe)
**Next call:
June 13, 2011 5:00 pm EDT (GMT-4), PIN: 0169152#
**New Action Items**
[AI] (Keith) will send a discussion starter on the use of eduCourse to the mailing list.
[AI] (Scott) will send a discussion starter on organizational attribute issues in attribute aggregation scenarios to the mailing list.
**Carryover Action Items**
[AI] (Keith) will issue a last call for eduPerson edits, beyond EPTID revisions, for inclusion in a forthcoming revision.
[AI] (Keith) will develop a Bamboo use case for persistent identifiers.
[AI] (Keith) will write up the current state of the identifier discussion and apparent consensus, and associated explanatory material, for use by REFEDs.
[AI] (Keith) will edit the previous versions of the SAML Attribute Profiles documents to note that they have been superseded by a newer
version:
http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-attribute-x500-cd-01.pdf
http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200604.pdf
http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-saml-attributes-20071202.pdf
http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200804.pdf
http://wiki.oasis-open.org/security/SstcSaml2AttributeX500Profile
http://www.oasis-open.org/committees/download.php/28042/sstc-saml-attribute-x500-cs-01.pdf
See also:
http://www.edugain.org/policy/edugain_policy_build20110124/attribute_profile_20101215.pdf
[AI] (RL "Bob") will query the REFEDs list about whether identifier reassignability is an issue for them esp. in grid environments.
[AI] (Keith) will take a first pass at revving http://middleware.internet2.edu/dir/docs/internet2-mace-dir-ldap-group-membership-200507.html in the wiki, then run it by the group for comment, with the goal of perhaps finalizing it in the near future.
[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.
**Discussion**
- Does Grouper make eduCourse obsolete?
Following up on a recent thread on the mailing list, others are interested in this topic as well. Consensus is that Grouper does not make eduCourse obsolete, e.g. because Grouper does not define SAML attributes for carrying course information.
Would it be useful to back off from stipulating that the eduCourse vocabulary is controlled, in terms of roles in a course in the IMS sense (instructor, learner)? Is defining these terms unduly difficult?
Ignoring values that are not relevant or defined sufficiently for a particular context is not necessarily problematic, in practical use.
eduCourse is currently being used by some institutions, and federating course information would be valuable in the context of sharing course information among cooperating campuses, however controlling the vocabulary becomes more important especially as you cross organizational boundaries.
It was noted that affiliation was designed originally to support searching, and overloading into an authz attribute has happened largely due to community practice. It is still used for searching, e.g. for analytics and reporting.
It would be useful to have more discussion on this topic on the mailing list.
[AI] (Keith) will send a discussion starter on the use of eduCourse to the mailing list.
- What changes may be needed to accommodate the anticipated growth of the practice of attribute aggregation?
- does it imply a need to use the RFC 822 address spec syntax (local-part@domain) for additional eduPerson attributes: eP{S}PrimaryAffiliation, eP{S}Entitlement,...
- it raises the thorny problem of who can authoritatively assert what.
It was suggested that eduPerson needs to address identifier proliferation and how to represent them, e.g. social identities. E.g. while you can consider Google to be an IdP and treat it as such, it does not assert EPPN.
Scope should not be related to who is actually asserting an attribute, e.g. anyone can assert your e-mail address as an attribute belonging to you. The data source is not part of the value, yet is still important and can be captured in other ways.
How would a rule enforcing who to accept attributes from be enforced? It could be a filter policy to accept or reject attributes from a certain source.
Is attribute aggregation something that institutions see using in the near- to mid-term? E.g. for multi-campus state systems, when a user from one campus attempts to access a library resource on another, the SP might see values from both the system and the individual campus.
Q: In EPPN, what does the scope refer to? Is there a different EPPN asserted in some circumstances?
A: Entitlement may be maintained at the system level, and thus attributes from both the system and individual campus may be asserted in some contexts.
In the case of a statewide IdP for K12, the granularity of individual schools and/or districts would present a similar situation. The question of user attributes (e.g. affiliation) v. who is asserting the attribute is present here as well. The question of how to ensure unique EPPNs would vary depending upon whether you are starting from scratch, or are integrating with existing infrastructure.
Organizational identifiers are going to be as important in the attribute aggregation context as individual identifiers, and thus need to be considered as well.
Q: For EPPN, can the principal name be something other than the user name?
A: It can be any identifier. There is no rule that it must be human-friendly, although this is often assumed in practice.
[AI] (Scott) will send a discussion starter on organizational attribute issues in attribute aggregation scenarios to the mailing list.
- Report & discussion: Advanced CAMP session on attribute options (i.e. labels), person-rooted subtrees and on complex attributes (complex as in the XML Schema definition of complex attributes). See https://spaces.internet2.edu/display/ACAMPScribe/Friday+10am+CottonCreek
(to be carried over to the next call)
- Suggested Future Agenda Item
Asserting a LoA for users taking standardized college admissions tests, and whether it might be attached to a social identity given that the vetting used to confirm the identities of users taking the test.
--
Steve Olshansky
Internet2 Middleware & Security Flywheel
http://www.internet2.edu/middleware/
http://www.internet2.edu/security/