MACE-Dir Working Group Session
Fall Internet2 Member Meeting 1-November-2010
**Review of Carryover Action Items**
[AI] (Keith and Chad) 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 on the next call in 4 weeks.
The lack of a generic API for group definition, stemming from the last Advance CAMP, was the spur for this. Integration without a standard is challenging...
Group memberships in a VO being used for the granting of access to specific resources was raised as an example use case, in the COmanage context. How can the group names be kept unique? Is it groups or permissions being asserted by the VO?
What groups are users in, and what are the memberships of those groups, are questions that would commonly need to be answered...
Should standards for group naming come from MACE-Dir, or somewhere else (where?)?
Collaboration environments, especially those crossing administrative boundaries, seem to be driving many of the group management discussions underway (e.g. COmanage).
Trust, e.g. who is allowed to make particular kinds of queries, comes into play as well in this context.
[A] (All) Volunteers for working on surveys about managing people entries, attributes, and affiliations from non-authoritative sources, contact David Bantz and SteveO.
Trying to bring some collective wisdom to this topic is the goal, since local practices apparently vary widely. Consensus was that this is a valuable effort and ought to be pursued.
It was noted that the US government is facing this as well in the context of LoA1, and thus referring to their documentation would be useful.
- Are self-assertions accepted, and if so, in what circumstances?
- Are group members representing themselves, or their home institutions, or both?
[AI] (RL "Bob") will craft a survey on use of the mail attribute and possible need for additional email attributes. This surfaced again at the recent TF-EMC2 meeting, in the context of a campus IdP serving Grid apps. E.g. what are RPs assuming an attribute means in a federated context?
Authoritativeness of e-mail addresses, i.e. self-assertions, is a driver. Using the federated attribute in place of e-mail address confirmation is a potential scenario, is this acceptable? Should the SAML attribute assert something different from the LDAP attribute?
The mail attribute in directories is populated in a variety of ways at different institutions.
DKIM, and what is it good for, was raised as an associated issue...
It was observed that LoA in the SAML context does not assert anything about the "quality" of the attributes being asserted.
[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.
CN may not be the right attribute to use with SPs.
---
Topics raised for potential future discussion:
- PESC is interested in looking at eduPerson and eduCourse with an eye toward making them "PESC standards" although it is unclear exactly what that would mean.
- Usage of eduPersonAssurance - is anyone using it, and if so, how?
- Usage of eduPersonTargedID - updates to documentation needed? Is it being widely used?
- Usage of eduPersonEntitlement - Are IdPs and SPs using it?
Outsourced services are a driver for much of this discussion... Internal uses, e.g. for student access to resources, can be handled by eduCourseMember in some cases.
- Identifier characteristics and usage
- Identifier efforts - ORCID, PubMed Author ID
Context was raised as an important element that must be considered...