This page is being used to collect additional generic use cases for Guest and Affiliate Systems. Please review the Use Cases captured on the Social Identity Wiki before added additional use cases here. Any authenticated Wiki user should be able to edit this page.
The Generic Use Cases listed on the Social Identity Wiki are equally applicable for the creation of a Guest system. The primary distinction is that for the use cases listed there, it might be possible to use a "Social Identity" rather than a Guest/Affiliate System.
The use cases below are broken up into those that could use either a Guest System or social identities, and those use cases where a Social Identity is not appropriate.
Guest System/Social Identity Use Cases
Guest System Specific (Non-Social Identity) Use Cases
Guest or Affiliate with Sponsored Access to Higher Risk Resource: A non-member subject requires access to a resource that has a higher risk of exposure and consequently requires a higher Level of Assurance (LoA).
Guest or Affiliate that must have Verifiable Contact Information:
Case 1: An affiliate working in a non-university position (private corporation, research organization, etc.), located within the campus boundaries requires a university proximity card for access to their building. They may or may not be required to authenticate to any campus resources. The University needs to have accurate location and contact information and know "when" this affiliate leaves employment so that the prox-card can be deactivated. (Guest/Affiliate System of Record)
Case 2: An affiliate working in a non-university position (private corporation, research organization, etc.), located within the campus boundaries is required to file HazMat reports with the Environmental Health & Safety department.
Guest or Affiliate in "Transitional" Role is issued a Campus Identifier: In some transitional roles, a subject might still be an affiliate of the university but with the expectation that they will become a student or employee in the near future. This is not the traditional "applicant" affiliation in a normal student/employee life cycle, but one where there is a reasonable expectation that the subject will become a campus "member". Examples might include a potential student in a summer program, a "trainee" or a potential employee in a probationary or temporary assignment. In order to make the transition into the Student or HR system easier, a Guest System is used to capture identity information (Guest System of Record)
Alumni Access Campus Resources:
Case 1: An institution might want to keep information about its alumni in a guest system (in addition to, or rather than an alumni database) as many alumni continue to use campus resources for some period of time after graduation.
Case 2: Many Alumni return to campus as a graduate student or employee, and being able to keep an active "guest identity" with their originally issued campus identifier(s) and PII allows them to be transitioned into the student or HR system if they return to the university.