Affiliation Types and Qualifiers

* faculty:retired is not an expected affiliation per current HR-policy, but might arise in transient situations based on a strict (and proper) interpretation of the HR data, for instance, the wrong JCC or during a window between retirement and emeritus status.
** Not all affiliate:sponsored people are in the administrative privgroup, only those that are sponsored directly by individuals in a department. This excludes certain bulk sponsorships, e.g., for summer conferences.

• Affiliation: This is expressed in two parts -- a primary affiliation type and an optional qualifier. This value is available to authorized applications in a directory attribute called suAffiliation. The value will either be a one-part unqualified affiliation code, e.g., "staff", or a two-part qualified code, e.g., "faculty:emeritus".
  • The four primary University affiliations, Student, Faculty, Staff and Affiliates exist in the context of a relationship with a contributing organization. The two organizations represented in the current Registry are Stanford and SUMC (Stanford University Medical Center, including the Hospital and Clinics). So affiliations are meaningful in the context of the organization in which they exist, and a fully qualified affiliation expresses organization, affiliation and optional qualifier together -- e.g., stanford:staff, stanford:faculty:emeritus, sumc:staff.
  • Note also that ALL non-Stanford affiliations rank lower than "stanford" affiliations, but within an organization are ranked per above.
• Display Value: A text expansion of the encoded values, suitable for presentation in a non-programmatic setting. Where an affiliation is shown in a directory entry, this is the value that will be used, though the presence of a display value does not imply a public directory entry.
• Rank: Precedent given to source systems data when examined for "best" value to be used in setting Registered Name, Email, Home Address etc. Note that values are generally arbitrary and relative only, though values 90 and above are considered "deprecated" sources -- they will only be used in the absence of any higher affiliation. A table ordered by rank is shown below.
  • No single ranking can be perfect for all needs. The principles underlying these ranking assignments were to place strong academic relationships first (student/faculty before staff), with student taking the top position because it has the most restrictive business rules that should be applied first. The critical example of this is that ferpa privacy rules need to take precedent over other visibility settings. The outbound Person XML document presents affiliations in their ranking order. Downstream systems that needs to know of specific relationships, e.g., "retired faculty" should understand that such a relationship might be present but not always the first/highest relationship shown.
• Stanford privgroups: One goal of this information is to provide a common definition of the current/active members of the Stanford community, one that would correspond to that set of people general embraced automatically by systems and services that support that community. It can stand alone, such as in rules for site-licensed software, or defining directory access limited "to authenticated Stanford Community". Or it can be just a useful starting point for determining eligibility or privileges.
  • The Stanford Community consists of all current/active faculty/staff and students. Membership in one of these groups, and in the Stanford Community itself, is expressed by the Privilege Groups maintained in the Registry as a reflection of current affiliations.
  • The stanford column (stanford_ind in the table) is the source of 2 privgroups. A "yes" in the stanford column indicates that there should be both a stanford:stanford privgroup, and a privgroup corresponding to the value in the affiliation type column -- stanford:student, stanford:faculty or stanford:staff. A blank in the stanford column indicates the absence of both privgroups.
  • The acad column (academic_ind in the table) indicates there should be a stanford:academic privgroup, while the admin column (administrative_ind in the table) indicates there should be a stanford:administrative privgroup.
  • Note that each affiliation "authorizes" the privgroups indicated, but only one privgroup of each kind should exist in the entry.
• Online Listing: a "yes" indicates a relationship that qualifies for a public directory entry (StanfordWho/whois).
• SUNet ID Eligibility: "Full" indicates eligibility for "regular" (i.e. free, University authorized) services. "Base" is for SUNet ID alone for authentication, but no services.

Here is a view of the affiliations table ordered by Rank. It shows the institutional bias towards academic over administrative affiliations, and shows that the priorities follow the "Stanford" community first. However, rules of eligibility and authorization do not necessarily follow such a neat pecking order, as shown by the representative service columns.

data history