Arlene Allen (SB), Christi Bengard (SC), Jim Dolgonas (OP), Chester Ferguson (BK), Kathy Keller (OP), Debbie Lauriano (DV), Helen Lee (BK), Bob Merryman (SD), Benny Min (OP), Caroline Rider (IR), Jerry Wilcox (OP), Don Worth (LA)

• on 07/07/98, Phase I "regeneration" completed - this process was run to "regenerate" Net IDs for everyone passed on the Payroll IVR-to-University Directory interface (originally completed on 04/30/98) per Authentication Unit request to effect this (one-time only) in early July; this thus did create new Net IDs for everyone and the daily University Directory-to-Authentication interface correspondingly process resumed, too, following its completion



• on the 08/22-08/23/98 weekend, a Payroll IVR-to-University Directory "refresh" process is scheduled to run - this process will basically "refresh" (dump and reload) all data in the Payroll IVR database, but it will NOT result in new Net IDs being created for all data in the University Directory; the daily University Directory-to-Authentication interface will resume once the "refresh" has completed
  
  
• still awaiting word from General Counsel

Issues (supplementing issues raised at prior meetings) and Conclusions:

• release flag "gradations" for a student in the University Directory was discussed and BK, IR, LA, and SD noted the level of detail they currently support in their local student applications; the following potential release flag values were then proposed for the University Directory to which all campus release flag values could be mapped:
  • data element "access" allowed and "services" allowed
  • data element "access" not allowed and "services" allowed
  • data element "access" not allowed and "services" not allowed

  Subsequent related action items proposed were:

  • providing 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
  • providing more clearly stated "policy" objectives for student data element "access" and "services" as referenced in the above proposed release flag values; also, to provide further clarity, an example "service" should be cited, e.g., inter-campus library privileges
  
  
• "multiple Net IDs per individual" discussions included a general conclusion that it was much more critical to reduce such cases within a campus population and relatively less critical to reduce it within the entire university population; proposals to reduce "multiple Net IDs per individual" included:
  • approaching General Counsel again
  • developing a "one-way hash" for the SSN that could be passed on the student interface and that would ideally limit SSN "exposure" concerns and still provide the necessary "unique ID" functionality to lessen the frequency of "multiple Net IDs per individual"

    note: data integrity issues RE: the SSN data element itself, more so, in student systems, was cited as a concern regardless of what is implemented; it was also noted that intermittent "pressures" have arisen to expand the PPSIVR population so that it is not limited to those UC employees who have a SSN- the impact on University Directory processing would also need to be considered were such actions to result
    
    

  • developing processes to take advantage of those campuses who have a campuswide ID (a.k.a. Universal ID); that is, such campuses would, in theory, be passing the same ID value on the PPSIVR (payroll) interface in the Employee ID field as on their student interface in the Student ID field; thus, University Directory interface processing could incorporate cross-referencing of these ID fields to lessen cases of "multiple Net IDs per individual", at least within a campus

    note: campuses might also pass the Net ID on the student interface if it is already known; this is already an optional field on the last proposed draft student interface specs (06/01/98)

  A related proposal was cited to develop a utility that could be deployed to campuses, at their request, which would facilitate generating the necessary student interface to the University Directory including the appropriate Add, Change, and Delete transactions in the standard, university-wide format
  
  

• use of PGP for data encryption was briefly discussed including current production usage in other applications; further discussion/assessment was recommended
  
  
• discussion of the "directory" interface specs (agenda item #3) was deferred until the next conference call

• propose next conference call dates/times soon with a basic agenda of first discussing "directory" interface specs and second, resuming discussion of student interface specs incorporating updates based on 08/20/98 call
• distribute meeting notes to group
• distribute updated draft for proposed new student interface specs to group as well as supporting documentation for release flag usage

Return to Meeting Agendas & Minutes Page