Seitenhistorie

This is a globally unique identifier that looks like an email address but does not have to be. (It can be a valid email address, if you want, but noone recieving the value as an eduPersonPrincipalName attribute should try to send email there.)

Many applications expect an identifier that's suitable to being shown in the interface once logged-in. I.e., there's an expectation that an identifier is (among other things):

• not very long (as persistent NameIDs are),
• not very ugly (again persistent NameIDs),
• and can ideally be recognized by the subject to be her own / represent herself.

Most applications also seem to expect that such identifiers never change, which combined with the other requirements (globally unique, not overly long, not ugly, known/recognizable to the subject) makes this impossible to fulfill at most academic institutions. I.e., you can't win and this no one attribute cannot can solve all the requirements people throw at it. 

 Practically Practically speaking there are only two reasonable ways to generate eduPersonPrincipalName values:

1. from the login name / userid, (from whatever local attribute, e.g. uid, cn, sAMAccountName, etc.) by appending the scope of the IDP (e.g. @example.ac.at) at the end, or
2. by re-using the email address as eduPersonPrincipalName attribute.

The first variant (uid login name + scope) has the disadvantage of exposing part of the login credentials (– though the login name/userid shouldn't generally be considered secret as there usually are many ways to discover it). But At least it's guaranteed to exist and can be assumed to be well-known to the subject (as it has to be entered for authentication purposes), at least in its "unscoped" form.
The second variant (reusing re-using email address values) has the problem that this only works if you're issuing email addresses in your domain (IDP scope) for all subjects that who should also should have an eduPersonPrincipalName attribute values (which is all your population, basically). This is required because SAML Service Providers check the scope (domain part) of eduPersonPrincipalName attibute values against the published (i.e., allowed) scopes of IDPs (column "scope") , in order to protect themselfs from IDP impersonation (i.e., one IDP impersonating subjects asserting vales from from another IDP). So if your IDM system hands over external email addresses to your SAML IDP (e.g. gmx, gmail @gmx.net, @gmail.com, etc.) you cannot re-use email addresses as eduPersonPrincipalName attributes (at least not for that part of the population where you store and provide the IDP with that only has external email addresses).

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

eduPersonPrincipalName Alternatives

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

• The subject-id attribute from the OASIS SAML 2.0 persistent NameIDs: Very different in basically all their properties. 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 it0 SubjectID Attributes Profile. This is the likely future replacement for most uses of eduPersonPrincipalName.
• Email address itself, and not email-address-dressed-up-as an eduPersonPrincipalName attribute-eduPersonPrincipalName (as discussed above): The commercial world ("cloud" / vendors/Internet monopolists/etc., Internet Monopolists) has long decided settled on email as the identifier, as evidenced by all the "log Log in with your email address" prompts all over the Webweb. (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 addresses as identifiers suffers suffer from all of the  the problems eduPersonPrincipalName does – plus others, plus additional 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 fail most "data minimisation" tests, and may therefore not be sufficient under GDPR/DSGVO. Sending email adress in an mail attribute also doesn't work for all applications that require an eduPersonPrincipalName attribute, of course.
  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