Seitenhistorie

This is a globally unique identifier that looks a bit like an email address but certainly does not have to be one. (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 attribute cannot solve all the requirements people throw at it. Practically speaking there are only two reasonable ways to generate eduPersonPrincipalName values:

1. from the login name / userid, 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 + scope) has the disadvantage of exposing part of the login credentials (though the userid shouldn't generally be considered secret as there are many ways to discover it). But 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 (reusing 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 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 one IDP impersonating subjects from another IDP. So if your IDM system hands external email addresses to your SAML IDP (e.g. gmx, gmail, 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 external email addresses).

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:

Most existing email addresses will not be suitable canditates for this attribute, due to its requirements for non-reassignment as well as opqaueness.)

eduPersonUniqueID Alternatives

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

• SAML 2.0 persistent NameIDs: Unless you have several SAML Service Providers all needing to recieve the same identifier for a subject (e.g. as part of a multi-party multi-site project) persistent NameIDs are preferable. Also, as per early 2017 c.e. many more SAML Identity Providers support persistent NameIDs, and hardly any support eduPersonUniqueID yet.
• eduPersonPrincipalName: Similar only in syntax. eduPersonPrincipalName is usually derived from the local login name (+ scope) or actually is a copy of the subject's email address. Both login names and email addresses eventually will be reassigned (i.e., given from one subject to another) at many organisations, which will also affect eduPersonPrincipalName values (Reassignment of eduPersonPrincipalName values is not prohibited by the eduPerson specification). In contrast, eduPersonUniqueID does not allow reassignment, ever. That in turn strongly suggests use of opaque (read: long, ugly) attribute values for eduPersonUniqueID, in order to avoid namespace depletion. The main advantage of eduPersonPrincipalName seems to be its wide existing deployment, though that comes at a price: You can't rely on much, especially not that a given eduPersonPrincipalName value will identify the same subject after some time (e.g. several years later).
• Persistent NameIDs plus eduPersonPrincipalName: An application needing stronger assurances that a given identifier represents the same subject over time than those eduPersonPrincipalName alone provides can store both the persistent NameID and eduPersonPrincipalName values. The application can then continue using eduPersonPrincipalName as usual, but with the addition that during login the concatenation of persistent NameID and eduPersonPrincipalName is compared to previously stored values. Since a persistent NameID itself is prohibited from being reassigned, a changed combination of persistent NameID and eduPersonPrincipalName values can be seen as a strong indicator that the eduPersonPrincipalName value has been reassigned. The application could then decide to treat the new combination of values as a difference subject.
• Email address: When used as an identifier email addresses suffer from the same reassignment issues as eduPersonPrincipalName (described above) – plus additional ones, e.g.
• SAML 2.0 persistent NameIDs: Very different in basically all respects. 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) has long decided on email as the identifier, as evidenced by all the "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 the problems eduPersonPrincipalName does – plus additional ones, not least the possibility of sending email to that "identifier", including spam. Also Also, sending releasing an email address to a service when only an identifier (y) 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 as belonging to them. Also, you don't have to explain what it is to anyone. (In contrast to eduPersonPrincipalWHAT?!).

Examples:

...

So eduPersonUniqueID is clearly the preferred choice if:

• your SAML Service Provider is part of a larger project that also involves other SAML SPs (and all those SPs need to reference a given subject by the same identifier, and those SPs are not localed behind a shared SAML proxy), and
• your application has strong requirements for non-reassignment of identifiers, i.e., if you need to be certain a given identifier represents the same subject even after many years of not having seen a login from that identifier, and
• you cannot or don't want to rely on using the combination of persistent NameID and eduPersonPrincipalName (as described above), which would give you some degree of "human palatability" (when showing eduPersonPrincipalName values in the application's interface) and equally strong arrurance of non-reassignment as eduPersonUniqueID provides (due to persistent NameIDs existing requirements).

But eduPersonUniqueID is also an acceptable alternative in basically all other cases where you already accept any of the following as primary identifier for a subject:

• eduPersonPrincipalName (maybe less so if you need to show the value to the logged-in subject and/or subjects will need to recognise others based on that identifier)
• persistent NameIDs
• email addresses (same caveat as for eduPersonPrincipalName above; plus sending email to eduPersonUniqueID usually won't work).

So following Postel's law it's recommended for SAML Service Providers to (also) accept eduPersonUniqueID, whenever a stable, unique identifier is needed.

...

Creating the attribute with Shibboleth IDP v3

...