Page History

REFEDS R&S and reassigned ePPN attributes

Note that if your deployment of the eduPersonPrincipalName (ePPN) attribute allows for reassigning ePPN values from one person to another that R&S v1.x requires that you to also release a SAML 2.0 persistent NameID then. Because SAML 2.0 persistent NameIDs prohibit reassignment that also releasing those enables R&S Service Providers (that care and do the work) to detect ePPN reassignments by always looking at the combination of ePPN and persistent NameID (instead of just at the ePPN): If one day a known ePPN arrives together with a different/unknown persistent NameID that's a sign that the ePPN likely has been reassigned to a different person and that access to the data held at the SP from/about the former ePPN-NameID combination should be denied.

Of course that assumes that you can and do support proper SAML 2.0 persistent NameIDs and that you create those from source data that itself is not reassigned from one person to another. (If you don't have any such data and you also cannot mint it on the fly, as illustrated in our IDP attribute resolver documentation, you cannot produce spec-conformant persistent NameIDs and therefore also cannot support REFEDS R&S v1.)

...