Page History

...

This is a globally unique identifier that syntactically looks like an email address or an eduPersonPrincipalName.

Compared to eduPersonPrincipalName it's main differences are:

• opaque (i.e., long, ugly, "privacy preserving") values
• a strict requirement that values may never be reassigned from one subject to another

See the eduPerson specification (linked above) for details of the definition. See below for implementation considerations and how eduPersonUniqueId compares to other common SAML attributes. See the IDP 3 Attribute resolution documentation for concrete implementation examples.

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. the possibility of sending email to that "identifier". Also, releasing an email address to a service when only an identifier is needed will fail most "data minimisation" tests, and may therefore not be sufficient under GDPR/DSGVO.

So eduPersonUniqueID is clearly the (formerly, i.e., until the new OASIS subject-id attribute is being deployed) 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 won't work).

...

Issues

• The eduPersonUniqueID attribute suffers from a case folding issue (due to allowing use of both upper and lower case characters) that may lead to identifier collisions at Service Providers not treating identifiers as case-sensitive. Consider this an informal Security Advisory against any use of this attribute.
• Also note that the new version of saml2int – which is a formal part of the eduID.at policy via the Technical Profile – goes much farther and states that:

SPs MAY support legacy or historical <saml:NameID> and <saml:Attribute> identifier content for compatibility reasons but MUST NOT require their use

...

.