Child pages
  • Research and Scholarship FAQ

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: fix claimed "recommended" status that also included ePSA; deemphasis ePSA based on R&S VC 2020-12-03

...

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: eduPersonScopedAffiliationvalues 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:

...