Seitenhistorie

...

Of course all variants here have the issue that email addresses (and sometimes even login names) occasionally change, e.g. when people change their names after marriage/divorce or religious convertion. And sometimes such identifiers might even be re-assigned from one person to another (the worse case), maybe after a required dormancy period of a few years. So applications relying on eduPersonPrincipalName (or any identifier that doesn't prohibit reassignment) will need to be prepared to handle such changes.

eduPersonPrincipalName Alternatives

For application integrators the potential alternatives to relying on eduPersonPrincipalName in the Higher Education and Research sector basically are:

• SAML 2.0 persistent NameIDs: Very different in basically all their propertiesrespects. Values for a subject at a given SAML SP cannot be known in advance and so this attribute cannot be used to provision or authorise access in advance (e.g. before the subject logs in at least once). Values are unsuitable for display to the subject, a practice some applications insist on. Moderately widely deployed globally.
• eduPersonUniqueId: An identifier that looks like an email address (like eduPersonPrincipalName), but can be somewhat longer (maximum 64 + @ + 256 characters) and is defined to be ugly/meaningless/opaque/unrecognizable-as-your-own. On the upside, this avoids most changes (noone will want to change their random-long-ugly identifier because of marriage; because it's long and ugly there's also no reason to ever show that identifier to the subject, let alone require her to know the identifier), and the fact that it's not name-based avoids namespace depletion (no more worrying about of running out of desirable, short, memorable identifiers derived from the subject's own name, or it's ugly alternative of re-assigning identifiers from one subject to another). Significant disadvantage (as per end of 2016 c.e.): eduPersonUniqueId is virtually undeployed across the globe, so services cannot rely on it, and therefore IDPs have little incentive to support it.
• Email address itself, and not email-address-dressed-up-as-an-eduPersonPrincipalName-attribute (as discussed above): The commercial world ("cloud"/vendors/Internet monopolists/etc.) has long decided on email as the identifier, as evidenced by all the "log Log in with your email address" prompts all over the Web. (Though those services usually have nothing to do with sending you email, or even with your email account. You'll usually also have to register an account locally and set Yet Another password for that.). Obviously email as identifiers suffers from all of the  the problems eduPersonPrincipalName does – plus othersadditional ones, not least that it's tautologically clear that you can send the possibility of sending email to that address"identifier", including spam. Also, sending email address when only an identifier is needed will fails most "data minimisation" tests, and may therefore not be sufficient under the upcoming GDPR/DSGVO.
  On the plus side, it's universally deployed, everyone has one (or can easily get one) and people usually know (and recognize, when shown) their own email address . Also you as belonging to them. Also, you don't have to explain what it is to anyone. ("In contrast to eduPersonPrincipalWHAT?!").

Examples:

• TCS Personal Certs
• Service Categories: REFEDS R&S