**MACE-Dir Call 4-October-2010**

**Attending**
Brendan Bellina, USC (chair)

Keith Hazelton, U. Wisconsin - Madison

Paul Hill, independent

Michael Pelikan, The Penn State U.

Scott Cantor, The Ohio State U.

Mark Scheible, NC State U.

Ann West, Internet2

Todd Piket, MN State Colleges and Universities

Tom Scavo, InCommon

Benn Oshrin, Internet2

Jim Leous, The Penn State U.

Renee Frost, Internet2

Mark Jones, UT-Houston

Bill Weems, UT-Houston

RL "Bob" Morgan, U. Washington

Derek Owens, Notre Dame

Steve Olshansky, Internet2 (scribe)

Next call: Oct 18, 2010

**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 Keith.

[A] (Keith) will follow up on the REFEDs list conveying the sentiments expressed on the call today about the eduPersonScopedAffiliation usage comparison.

[AI] (Mike) review the LocalDomainPerson survey results and the Shibboleth attribute naming documentation with an eye toward useful attributes to generalize, as a reference for naming guidelines and base attributes to propose.

http://middleware.internet2.edu/dir/localsurvey.html

http://middleware.internet2.edu/dir/docs/internet2-mace-dir-localdomainperson-200505.html

[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.

[AI] (Brendan) will coordinate with the leaders of the Educause IdM Constituent Group, toward the goal of polling that group along with MACE-Dir for feedback on the use of commercial and open-source IdM products.

**Discussion**

- Discussion as to whether eduPerson specification should have an additional identifier attribute added that would be persistent, as opposed to the existing ePPN attribute which is not. Should such an attribute be added? If so, what should its other characteristics be? What are the use cases for this attribute in a federation context?

For further information on this see the recent thread on the MACE-Dir mailing list about "persistent identifiers" initiated by Tom Scavo 9/30/2010

Tom provided some context: His goal is for the SP to be able to formulate attribute requirements in some manner, using requested attribute elements based upon the SAML attribute type, with the addition of an XML field isRequired.

Enabling a SP to request attributes in some generalized way would be useful...

EPPN has properties that are not defined but may be true for certain IdPs. How can SPs formulate attribute requirements and ask for identifiers with certain properties? Is a new attribute required? Or could a particular existing identifier be requested with certain properties?

It was observed that an SP could request particular attributes with certain characteristics (properties) as policy.

Reassignment was raised as an important property. Some eScience groups have stated they only really want non-reassigned identifiers for authn to their environments.

Currently these sorts of attribute characteristics requirements are addressed OOB between the parties involved, rather than on the wire (e.g. in the metadata).

In InCommon, the POP covers the reassignment of EPPNs, and SPs theoretically ought to be reviewing POPs...

To date, eduPerson has defined attributes to be released, but now we are moving to discussing information about attributes released on the fly.

It was proposed that identifiers with differing characteristics merit their own attributes.

EPTID is designed to allow for the privacy preserving (i.e. non-correlatable) case, but not require it, so perhaps it could be used to satisfy these requirements within Shib with little coding effort. But it was observed that using EPTID in a non-privacy-preserving manner would be confusing...

It was noted that in many cases when EPTID is used, library and medical communities in particular are typically very interested in preserving privacy. However many other kinds of SPs which are supplied EPTID still require e-mail addresses or other identifying information about the user (e.g. wikis), eliminating the privacy aspects of it.

If you start from the premise that a particular site is unable to deploy and maintain pair-wise EPTID (e.g. due to DB/clustering requirements), they can't supply an identifier is useful to preserve privacy. Defining a new attribute won't help this...

Q: If EPTID is not stored in a DB, but rather is constructed on the fly and released to a particular (one) SP, what is the flaw?

A: The values can't be changed if it is compromised, nor can handle SPs changing their entityIDs.

When an SP has a new user appear and authenticate, and needs attributes from other SoAs to determine if that user is authorized to do what s/he is seeking to do, EPTID becomes problematic. This scenario is becoming increasingly common in higher ed. How can a global IdM infrastructure be "plug-and-play" while still preserving privacy where required?

Given the options discussed, where to from here? Some additional documentation of the use cases would be helpful to frame the inevitable future discussions on this topic. The UT folks will be working on this from their perspective.