Page History

...

• faculty: wissenschaftliches Personal
• staff: allgemeines Personal, oder sämtliches Personal, wenn wissenschaftliches Personal nicht existiert oder nicht unterschieden wird.werden kann
• employee, : sämtliche/s Angestellten/Personal
• student, Studiernde: Studierende
• member, : if the subject has any (i.e., at least one) of the above affiliations, plus possibly other subjects that fit the eduPerson-defined criteria for member.
• alum, : for alumnæ/alumni (former graduates), if available in the same Identity Management systems 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.
  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 certainly 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.

...