**MACE-Dir Call 15-November-2010**
**Attending**
Brendan Bellina, USC (chair)
Mark Jones, UT-Houston/TMC
Keith Hazelton, U. Wisconsin - Madison
Benn Oshrin, Internet2
Cory Scofield, U. Victoria
Scott Cantor, The Ohio State U.
Tom Barton, U. Chicago
Tom Scavo, InCommon
RL "Bob" Morgan, U. Washington
Steve Olshansky, Internet2 (scribe)
**Next call: Nov 29, 2010
**New Action Items**
[AI] (Keith) will summarize and propose a near-term solution to the identifier reassignability issue
**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.
[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.
1. Review of new areas for potential work in MACE-Dir:
(RL "Bob") Modernizing the usage requirements in eduPerson in support of federation
RL "Bob" referenced a recent document citing ways of transferring information about students, which stated that eduPerson is only usable for looking up information in an LDAP schema, and not for attribute assertions, which is counter to significant usage in the wild.
Recasting eduPerson, redefining attributes, is probably overkill reinvention. However, some minor spruce-up of the spec is probably appropriate, to overtly reference the attribute uses in e.g. the SAML context.
(Keith) Identifiers in context for Service Providers
- Grid requirement for persistence
This is a follow-up from the Federated Identities for CI workshop in Atlanta.
http://workshops.cilogon.org/2010
There were suggestions that it is pointless to give abstract generalized definitions of identifier properties, since they are really context-specific. Perhaps it makes more sense to view this from the SP perspective in a few specific cases.
E.g. for a grid SP, with a returning identifier used for access to services and resources, there is a clear need for the SP to be able to assume that the user represented by this identifier remains the same over time (i.e. it hasn't been reassigned).
As an example, a federation POP could state that for EPPNs, reassignment may happen but only after a n-year hiatus so prior associations lose relevance. For the TeraGrid, a hiatus period longer than one year would meet their needs.
Or there could be a time stamp associated with an EPPN for a given assertion, declaring the assignment date, and the SP could potentially use this info to inform an access decision. Is this overkill?
While persistence and non-reassignability are not addressed in these 2 examples, they may meet the needs at hand for many (but probably not all) SPs.
For EPPNs that do get reassigned, in practice this rarely happens in under one year.
Usability of the identifier for creating ACLs was cited as a key issue in seeking solutions. Using an opaque identifier could address the reassignability problems, but creates its own usability issues.
The privacy characteristics of EPTID (the inability to associate with a userid), for some applications, can become problematic...
Requiring SPs to negotiate attribute characteristics with every IdP is overly burdensome, and thus a generalizable solution would be valuable.
[AI] (Keith) will summarize and propose a near-term solution to the identifier reassignability issue
(Brendan) Assessment of attributes in real usage (in federated scenarios)
- epTID
- eduPersonAffiliation
- eduPersonAssurance
- isMemberOf
Would a survey be useful, to inform our future work in this area? Or perhaps asking for use cases from the community would be better?
Would an InCommon subgroup be a more appropriate shepherd for this activity than MACE-Dir? Or CIC?
(Keith) Growing need for metadata on Attributes
- representing assurance
or is this metadata on authn?
- representing provenance
- attribute descriptions for use for end users
This has been bubbling up in the federation context. There are other loosely-related particulars that will be addressed later if there is sufficient interest.
Attribute policy requirements from SPs are probably an interesting research topic, but in light of other more pressing issues this might best be tabled for now...
(Brendan) Governance of attributes
- determining of "student", "staff", "faculty", "member"
- policy or governance around release of attributes - internally, externally
- classification, handling, and release of personally identifying attributes
- syntax of attributes
A registrar is the authority for what defines a "student" on a campus, policy-wise. HR is similarly the authority for "employee." Is this sufficient to instruct the technology pieces that use these terms?
Is there a need for better documentation to clarify these issues?