*Participants*

Keith Hazelton -- Wisconsin (chair)
Tom Barton -- Chicago
Steve Olshansky -- Internet2
Todd Piket -- Michigan Tech
Barry Ribbeck -- UTHSC-H
Bob Talda -- Cornell
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

eduPerson E-mail Attributes

A thread of e-mails had preceeded the call on this topic which Bob aggregated into a single document, bringing it before the group as a whole seeking direction.

Tom "has a real sympathy" with the fact that looking for a unique e-mail for someone is a lot like looking for a unique identifier. This is compounded by the fact that a lot of the world and a lot of applications treat e-mail as a primary identifier for lack of a broadly deployed true identifier. The explicit goal of the sip.edu effort is to leverage e-mail addresses as identifiers for phoning people. Barry can think of several other important applications that would rely on a unique institutional e-mail address. S/MIME, which leverages PKI to sign e-mail, requires the ability to consistently look up a certificate provided the e-mail imbedded in a message. "The long-term answer is to fix the stupid clients, but the answer right now is, the e-mail field in the cert you were given has to be the e-mail address in the "from" field." The additional Reply-To field is not affected. Mail forwarding is another issue. There are known advantages to having a layer of indirection between the publically available e-mail address and internally or institutionally available addresses, although this requires some technical and policy work. One persistent issue is whether it is fair to require every individual associated with a campus to be able to receive mail at an e-mail address, and, if so, at which point in the admittance/hiring process does this requirement come into effect?

Unique Addresses

This tailed into another discussion about the different mechanisms by which a unique e-mail address could be generated for every individual on the campus while maintaining some degree of consistency. Barry talked of a formal group presented with a number of different solutions, which were framed within the context of the scale of any given institution. For vanity and other purposes, they settled on first.middleinitial.last@institution. This led to a collision rate with the scale of their namespace on the order of 1 or 2 within 10,000. Citing a particularly surprising example, they hosted two "Bulent Dojent"s, who were not related in any way and didn't even come from the same country.

When the inevitable collision occurred, a .uniquifier was slapped after "last". There were also workarounds to accommodate extremely long names anyway, increasing the necessity for this provisioning. It's also not clear that it is even okay to include an individual's legal name in their e-mail address, because at this point there are concerns that it would be considered directory information under FERPA. That would require the campus to suppress this information somehow, and lead directly to opaque usernames.

Use of e-mail as a primary identifier may prove to be an ugly-but-necessary approach because there will be many application issues if it isn't: maybe Sympa won't integrate well with your Shibboleth origin, or S/MIME won't work well, or it won't be possible to dial a SIP phone using e-mail. In most cases on the web these days, the required unique field is e-mail because it's globally unique and guarantees one account, which is usually owned by one individual. An individual can keep multiple, which may or may not be desirable.

Pick your Own?

Chicago has been using very successfully for a long time a process that allows users to self-select e-mail addresses; Michigan Tech is migrating to this model now. Keith likes this approach, too, though it has its downsides; it is difficult to assign e-mail addresses, and there are some cases in which it would be desirable to know a user's username before they have claimed an e-mail address. If a temporary is given, then it must be changed in all the systems; similarly, if the user decides to change their selection, changing a username is painful, poorly automated, and error-prone.

Deliverables

There are two primary documents that could come out of this: additional eduPerson attributes related to institutional e-mail address, which may or may not then be used as an identifier depending on subsequent discussion, and a best practices for e-mail and identifier assignment on campus.