**MACE-Dir Call 29-November-2010**
**Attending**
Brendan Bellina, USC (chair)
Keith Hazelton, U. Wisconsin - Madison
Benn Oshrin, Internet2
Nate Klingenstein, Internet2
Michael Wheeler, Pittsburg State U (Kansas)
Ann West, Internet2
Bill Weems, UTHSC-H
Mark Scheible, NC State
Scott Cantor, The Ohio State U.
Tom Barton, U. Chicago
Tom Scavo, InCommon
RL "Bob" Morgan, U. Washington
Steve Olshansky, Internet2 (scribe)
**Next call: Dec. 13, 2010
**New Action Items**
[AI] (RL "Bob") will query the REFEDs list about whether identifier reassignability is an issue for them esp. in grid environments.
[AI] (Keith) will draft some text to provide guidance to users about the utility of eduPerson in federated scenarios, for use on the eduPerson web page.
**Carryover Action Items**
[AI] (Keith) will summarize and propose a near-term solution to the identifier reassignability issue
[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.
[A] (All) Volunteers for working on surveys about managing people entries, attributes, and affiliations from non-authoritative sources, contact David Bantz (db@alaska.edu) and SteveO (steveo@internet2.edu).
[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?
[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**
1. Grid Resource Provider user identifier requirements: Setting out on the path to resolving this one identifier use case.
- See http://bit.ly/grid-ids
Grid RP administrator requirements on person identifiers in federated use cases
1. The link between a given identifier and a given real world person should be persistent over time to the degree possible.
2. Once an Identity Provider has asserted a link between an identifier value and a real world person, the IdP should not reassign that identifier to a different individual. If the IdP does reassign identifiers, the IdP must accommodate the RPs' need to manage reassignment-based risks.
It was observed that in the real world, identifiers do get reassigned sometimes, usually after a reasonable hiatus (typically at least one year), and RPs understand and deal with this in a way that meets their access control needs.
If an IdP has a practice of reassigning identifiers (esp EPPN), each IdP would determine their own hiatus period. After this period, the identifier *may be* assigned to a different user. It was proposed that IdPs state their reassignment hiatus period publicly, perhaps in its POP, so that RPs could easily determine this.
3. It should be easy for RP administrators to read and enter identifier values, and associate these identifiers with other known attributes of the person's digital identity.
This is typically important for apps such as wikis in which easily mapping an identifier to a user is important. However should this be made a requirement?
EPPN does not meet this requirement per the spec, although most EPPNs do. E-mail is the only common inter-domain attribute that generally meets this requirement.
If presented with an identifier for an individual by a RP, it must be possible for the IdP to be able to identify the associated human when needed, e.g. for incident response.
It was noted that evangelizing and encouraging/recommending deployment of various attributes (e.g. EPTID) is really something that should be undertaken by InCommon or other federations among their participants, rather than by MACE-Dir. However refining the eduPerson language (#2 below) is in fact something that MACE-Dir ought to do.
In addition, documenting best practices around the use of particular attributes *is* something that MACE-Dir could and arguably should be doing.
The question arose as to whether other Grid environments (e.g. in the EU) have similar issues around identifier reassignability.
[AI] (RL "Bob") will query the REFEDs list about whether identifier reassignability is an issue for them esp. in grid environments.
Candidate eduPerson attributes and their fitness to these requirements
• eduPersonPrincipalName: meets #1 (persistence); #2 (non-reassignability) depends on IdP practices; meets #3 (associativity)
• eduPersonTargetedID: meets #1, #2 but not #3 directly
Issues to be addressed:
• eduPersonPrincipalName weakens privacy by its easy associativity and by the fact that all RPs receive the same value
• eduPersonTargetedID's non-associative values make access control administration more cumbersome and less readily understood
• eduPersonTargetedID is not yet widely supported by IdPs
Possible resolution of issues:
• Have each IdP determine the minimum number of years before a once-assigned eduPersonPrincipalName will ever be reassigned to a different individual. Call this the "ePPN hiatus period" and recommend that it be published in a well known and accessible place.
• Promote broader support for eduPersonTargetedID
2. Clarifying the utility of eduPerson in federated scenarios (it's not just for LDAP anymore)
[AI] (Keith) will draft some text to provide guidance to users about the utility of eduPerson in federated scenarios, for use on the eduPerson web page.
3. Developing recommended practices for attribute mongering by federations and their participants
- How do we assess real-world usage of attributes in a way that helps us draft recommendations?
4. Other urgent MACE-Dir work items
- See http://bit.ly/work-items
1. Extensibility via new attributes vs extensibility via new values for existing attributes
o If we have groups and entitlements, what more do we need?
o If we have globally unique values, do we even need groups and entitlements?
2. Standardized Group APIs
3. Real World Attribute Creation, Adoption and Usage
4. Attributes Supporting User Consent
5. Attribute Assurance and Provenance
5. It was proposed that we change the call time to better accommodate European participants. This will be discussed on the mailing list.
6. The K12 community is interested in suggesting some attributes for inclusion in eduPerson to meet their particular needs in federation. This will be discussed on a future call.