**MACE-Dir Call 24-January-2011**

**Attending**

Brendan Bellina, USC (co-chair)

Keith Hazelton, U. Wisconsin - Madison (co-chair)

Todd Piket, MNSCU

David Bantz, U. Alaska

Scott Cantor, The Ohio State U.

Chris Bongaarts, U. Minnesota

Benn Oshrin, Internet2

RL "Bob" Morgan, U. Washington

Ann West, Internet2

Tom Barton, U. Chicago

Tom Scavo, InCommon

Steve Olshansky, Internet2 (scribe)

**Next two calls:

In two weeks: February 7, 2011 at 11:00 am EST (1600 UTC/GMT)

In four weeks: Feb 21, 2011 at 5:00 pm EST (0000 UTC/GMT)

**New Action Items**

[A] (All) Volunteers for working on surveys about managing people entries, attributes, and affiliations from non-authoritative sources, please edit the working draft in the wiki

(Linked from https://spaces.internet2.edu/display/macedir/MACE-Dir+Working+Group+Space)

[AI] (Scott) will further refine the proposed EPTID text and resend to the mailing list.

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

[AI] (Keith) will summarize and propose a near-term solution to the identifier reassignability issue

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

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

[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. MACE-Dir thread "Persistent identifiers in education"

Use cases from ORCID and VIVO were cited as examples, for an identifier covering all of their purposes by users who have opted in to using that identifier. Should they be managed by institutions that the user has a current relationship with? Given that these identifiers would need to be portable throughout a user's professional lifetime, assumptions around their use would argue for them being discrete attributes.

Focusing on RP requirements seems to be appropriate early on...

Generally, trying to make an identifier "friendly" (e.g. e-mail style) would mean losing the non-reassignability characteristic. EPTID would seem to fit many or most of the requirements expressed publicly to date, if only it was adopted.

If there are use cases for which EPTID *WOULD NOT* work, it would be useful to hear about them now...

The Grid use case didn't have portability as a requirement, just non-reassignability. EPTID is apparently addressing this need.

The distinction between portability and correlatability was observed. Correlation is really about use cases in which the desire is to correlate records across data repositories. A specialized use of EPTID would work for this, as would using a global value tied to all instances of a record wherever it lives.

Trying to standardize around a method for achieving non-reassignability in the federation context would be good, but likely somewhat challenging.

Sharing medical records between providers was suggested as another potential use case, but is so special-purpose in nature that it was declared out of scope for this discussion. A properly-scoped EPTID may work for this, if the appropriate software supported it.

Anyone with use cases not yet discussed in this context are encouraged to float them on the mailing list...

Consensus on the call was that it is time to drop this topic for now, until raised later with other use cases.

2. Thread "Proposed eduPersonTargetedID text changes"

(See mail thread about this on the mailing list started by Scott Cantor 23-Jan-2011)

Scott observed that he is focused on the semantics of the identifier from the perspective of the RP, and there are discussions around deployment that don't really belong in the spec itself.

If the SP cares about breaking through the privacy-preserving layer, EPTID is not the appropriate attribute. The focus is really on what you need to assume about the attribute as an RP.

Q: Might SPs be reluctant to require EPTID instead of EPPN?

A: E.g. wikis want a friendly identifier, and don't really care about reassignment. If non-reassignment is absolutely required, then EPTID is what must be used.

Q: What are the properties of EPPN that are valuable beyond e-mail address?

A: Topic for an interesting discussion...

[AI] (Scott) will further refine the proposed EPTID text and resend to the mailing list.

The goal will be to bring this to closure by the next call in two weeks.