Page History

For eduID.at members we recommend the following mapping to eduPerson-standardised values:

...

• faculty: "wissenschaftliches Personal" (see linked Wikipedia article for how that maps to English-language terminology)
• staff: "allgemeines Personal" is the complementary antonym to faculty, meaning supporting, administrative, non-teaching, non-research personnel. (The terms are antonyms, not that an individual couldn't have both roles.)
  N.B.: staff was historically used within eduID.at in the UK sense of "all people who work here". Such use is discouraged nowadays (use employee instead, see below).
• employee: all personnel, whether faculty or staff. Use this if you cannot differentiate between faculty and staff within your IDM system or SAML IDP.
• student: "Studierende", specifically students in tertiary education (i.e., ISCED levels 5 and above; at earlier levels they are called "Schülerinnen"/"Schüler" in German, akin to UK use of "pupil").
• member: applies (and needs to be asserted) if the subject has any (i.e., at least one) of the above affiliations – plus possibly other subjects who fit the eduPerson-defined criteria for member.
• alum: for alumnæ/alumni (former graduates), if available in the same Identity Management system(s) your IDP accesses.
• affiliate: only if none of the above are applicable but you still need to express some kind of defined relationship with the organisation, i.e. affiliate should not be assigned if the subject has any of the above affiliations. Note that it's perfectly fine to not assign any affiliation value, though, so often no value will be sufficient (and is semantically equivalent to "none of the defined values") and therefore preferable over ma(r)king those affiliate gratuitously.
• library-walk-in: Special case only relevant for IDPs that need to support "patrons" of their public libraries (and where the accessed resources rely solely on SAML attributes for authorisation puposes, which is still very rare). That may include subjects with (only) a library card, or subjects physically present in a library location, e.g. based on IP address authentication.
  Don't use this for authorisation to licensed content if the provider can also accept the "common-lib-terms" entitlement instead, c.f. Library Services. And of course you don't need to worry about this at all if accessed resources allow authorisation based on location (IP address ranges), as the physical library location itself will already be sufficient to allow access. Also, if proxies, tunnels or VPNs are in use (to make remote subjects appear to be coming from the local data network) this affiliation – and SAML attributes and WebSSO itself – usually does not matter at all.

...