Page History

...

Service Providers should reference the eduPerson specification for details on values that may be received per attribute, but in general terms:

• eduPersonPrincipalName, eduPersonTargetedID, displayName are single-valued.
• givenName givenName + sn sn, email address, eduPersonScopedAffiliation can be mutli-valued.

For IdP Operators

What attributes

...

have to be released by an R&S IdP?

The Research & Scholarship specification defines a bundles of attributes that Identity Providers are encouraged to supporting R&S must release to R&S services:

• personal identifiers: email address, person name (either displayName or givenName+sn; ideally both forms to help applications that can only deal with one form), eduPersonPrincipalName
• If eduPersonPrincipalName
• pseudonymous identifier: eduPersonTargetedID
affiliation: eduPersonScopedAffiliation
• values may be re-assigend at a given IdP (from one person to another, even after a grace period) a SAML 2.0 persistent NameID (or eduPersonTargetedId attribute, though deprecated) must also be released by that IdP.
  (Persistent NameIDs may not be re-assigned, so R&S SPs that

The bundle also includes one optional attribute (everything else above being mandated by the specification):

• eduPersonScopedAffiliation

Service Providers should therefore be prepared to not receive affiliation attributes under R&S, due to their optional nature.
Affiliations in the form of eduPersonScopedAffiliation attribute values have long known to be not widely interoperable (REFEDS Whitepaper, A.Cormack, M.Linden, 2009) particularly in cross-institutional, cross-cultural or international uses. (As pointed out in the conclusion of said whitepaper affiliations are also unsuitable for most kinds of authorization use-cases, them being too "high level").  For these reasons their use within R&S is not emphasized or recommended.

Category support is defined as follows:

...