Seitenhistorie

...

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 usually 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 variant (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 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 over external email addresses to your SAML IDP (e.g. @gmx. gmxnet, gmail @gmail.com, etc.) you cannot re-use email addresses as eduPersonPrincipalName attributes (at least not for that part of the population that you provide the IDP with external email addresses for).

...

• The subject-id attribute from the OASIS SAML 2.0 SubjectID Attributes Profile. This is the likely future replacement for mostl uses of eduPersonPrincipalName.
• 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, i.e., not all IDPs support them.
• 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/divorce; 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 mid 2018 c.e.): eduPersonUniqueId is virtually undeployed across the globe. So services cannot rely on it, and therefore IDPs have little incentive to support it. Also, eduPersonUniqueId is itself going to be replaced with the subject-id attribute from the OASIS SAML 2.0 SubjectID Attributes Profile.most uses of eduPersonPrincipalName.
• Email address itself, and not email-address-dressed-up-as-eduPersonPrincipalName (as discussed above): The commercial world ("cloud" / vendors/, Internet Monopolists) has long decided settled 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 addresses as identifiers suffers suffer from all the problems eduPersonPrincipalName does – plus additional ones, not least the possibility of sending email to that "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.
  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?!).

...