This document proposes a University Directory policy for "Student Release Flag" functionality for student data passed from local campus student systems on the proposed new, daily student interface feed.

Table of Contents:

• Campus Student Release Flags
• University Directory Student Data Usage
• Student Interface Data Elements
• University Directory Student Release Flag Values
• Examples

Campus Student Release Flags:

Campus student systems currently support "Release Flag" values reflecting a wide range of granularity, e.g., ranging from one campus whose students can select one of two levels: 1 - to suppress publication of their information in the student directory or 2 - to indicate that all information about the student cannot be released to anyone, outside of use in direct university business requirements; to other campuses which support a far greater number of student "Release Flag" permutations; for example, allowing Student Name and Email Address dissemination, but not Student Local Address and Phone Number dissemination.

University Directory policy should support practices in place at all campuses.

To do so, it must provide for multiple rather than just a single release flag field on the student interface, again, in light of the granularity currently supported by at least some of the campuses; for example, there could be a release flag for "student name" and a release flag for "student address", etc. rather than just a single release flag for all student data in the University Directory.

University Directory Student Data Usage:

Processing student data in the University Directory supports the following usage objectives:

• to support universitywide authentication; more specifically, the University Directory should generate a unique value, a.k.a. the Net ID, to be housed in the payload of client-side, x.509 digital certificates for students; uniqueness is defined here to mean that the same Net ID value must not be assigned to more than one student
  
  
• to support both intra-campus as well as universitywide application development

  note: student data will not be used in universitywide "employee self-service" applications planned for development as part of Employee Systems Task Force (ESTF) project objectives; thus, other than the Net ID itself, no new and/or updated student data is required to be passed back to the campus student systems

Student Interface Data Elements - based on 08/31/1998 proposed new Campus Student System daily interface specs

• Student Record Code
• Student Location Code
• Student ID (a.k.a. Registration Number)
• UC Student Vendor ID
• Social Security Number
• Net ID
• Student Last Name
• Student First Name (middle)
• Student Release Flag (5 iterations)
• Student Type
• Student Status
• Student Term Begin Date
• Student Term End Date
• Student College (up to 3 iterations)
• Student Major (up to 3 iterations)
• Student Local Address 1
• Student Local Address 2
• Student Local Address - City
• Student Local Address - State
• Student Local Address - Zip Code

University Directory Student Release Flag Values:

• 9 - data element "display" allowed and "application services" allowed
• 1 - data element "display" not allowed, but "application services" allowed
• 0 - data element "display" not allowed and "application services" not allowed

These values will be applied to student data elements housed in the University Directory as follows:

1. Student Name (Last, First, or Middle)
2. Student Local Address (1st line, 2nd line, City, State, Zip Code)
3. Student ID (a.k.a Registration Number)
4. Net ID (for students)
5. all other student data elements (except for student's Social Security Number which is not displayed or "prompted for" in student applications to be developed)

Examples:

Suppose a universitywide application is developed to support student inter-campus library book borrowing. That is, an undergraduate UC Berkeley History student could go the UCLA undergraduate library and try to borrow a book upon providing identification. The application could then return confirmation that he or she is a current UC Berkeley student. Additional data for that student could also be displayed if authorized.

notice-and-disclaimer: The above example application does not currently exist and specifications for such a new application have not yet been defined. This fictitious application is only being described above in an attempt to clarify usage of the Student Release Flag values.

1. Suppose Student A has the following Student Release Flag values:
   • Student Name = 9
   • Student Local Address = 1
   • Student ID = 9
   • Net ID = 1
   • all other student data elements except for SSN = 9

   Student A could then provide his or her student information to the librarian who would enter it into the application and would then see the following data for that student displayed: Student ID, Student Name, Student College, Student Term Begin Date, and Student Term End Date; Student Local Address, however, would not be displayed. The librarian would also see displayed a generic confirmation message that the student is indeed a current University of California student.
   
   

2. Suppose Student B has the following Student Release Flag values:
   • Student Name = 9
   • Student Local Address = 1
   • Student ID = 9
   • Net ID = 1
   • all other student data elements except for SSN = 1

   Student B could then provide his or her student information to the librarian who would enter it into the application and would then see the following data for that student displayed: Student ID, Student Name; no other student data, however, would be displayed. The librarian would also see displayed a generic confirmation message that the student is indeed a current University of California student.
   
   

3. Suppose Student C has the following Student Release Flag values:
   • Student Name = 0
   • Student Local Address = 0
   • Student ID = 0
   • Net ID = 0
   • all other student data elements except for SSN = 0

   Student C could then provide his or her student information to the librarian who would enter it into the application and would then see displayed a generic message that the student has not been found; it wouldn't differentiate between whether the student data had been found or not in the University Directory and the bottom-line would be that Student C could not "use" this application service.
   
   

4. Suppose Student D has the same, following Student Release Flag values as Student C:
   • Student Name = 0
   • Student Local Address = 0
   • Student ID = 0
   • Net ID = 0
   • all other student data elements except for SSN = 0

   If Student D provides his or her student information to the librarian, he or she who would still see displayed a generic message that the student has not been found; however, suppose Student D was also an employee with corresponding Employee Release Flag values that allowed both Employee data element "display" and "application services"; then, if Student D provides his or her corresponding employee information to the librarian, he or she would see the corresponding employee data displayed and the librarian would also see a generic confirmation message that the student/employee is indeed a current University of California employee.