Skip to end of metadata
Go to start of metadata

Document Status:  undergoing stakeholder review


Goals of this policy:

  • Give applications access to directory data, consistent with UW privacy policy.
  • Reduce complexity by aggregating attributes into sets.
  • Ease access decisions for data stewards by characterizing applications, establishing blanket pre-approvals.
  • Provide granularity of control to allow different data stewards to define different access policies.
  • Support all current and near-term future Person Directory Service attributes and values.
  • Live within limitations of current Person Registry and White Pages operations, while being consistent with next steps in those systems.
  • Support, as soon as possible, a set of known clients who have been waiting for access; also other clients, in particular departmental clients, on a controlled basis.

Attribute Sets

Attribute sets are defined based on sensitivity and affiliation.

Attribute Sets

Entry metadata (distinguishedName, objectClass, createDate etc)
RegistryID (uwRegid, serialNumber, uwPriorRegid)
UW NetID (uwNetID, uwPriorNetID)
Test (uwTest)
Name (sn, cn, uwPersonRegisteredName, uwPersonRegisteredSurname, uwPersonRegisteredFirstMiddle, displayName)
Affiliation (eduPersonAffiliation)
Basic Directory Listing Preference (uwWPPublish)


Student ID Number (uwStudentID)
Student System Key (uwStudentSystemKey)
Student Name (uwSWPName)
Student Contact Data (uwSWPPhone, uwSWPEmail)
Student Directory Listing Preference (uwSWPPublish)
Student Class Code (uwSWPClass)
Student Departments (uwSWPDept1, 2, 3)


Employee ID (uwEmployeeID)
Employee Name (uwEWPName)
Employee Directory Listing Preference (uwEWPPublish)
Employee Campus Contact Data (uwEWPPhone1, uwEWPPhone2, uwEWPEmail1, uwEWPEmail2, uwEWPDept1, uwEWPDept2, uwEWPTitle1, uwEWPTitle2, uwEWPAddr1, uwEWPAddr2, uwEWPName, uwEWPMailstop, uwEWPVoicemail, uwEWPTouchDial, uwEWPFacsimile)


Advance ID Number (uwDevelopmentID)

As additional attributes become available, they may be added to existing sets or put into new sets, based on similarity to use and sensitivity of existing attributes, and policy requirements.

Client Types

Clients are typed to support blanket approvals by data stewards.  The types are:

  • Central Business Unit Applications:  supporting processes managed by UW central business units, such as HR, Academic Affairs, Budget, Health & Safety, Facilities, C&C, etc.
  • Departmental Applications:  supporting official UW processes in departments, institutes, programs, etc.
  • All other. 

In addition, to deal with data sensitivity regarding Name attributes in the Basic set in their current state, a set of Risk Factors (see Directory Data Exposure Risk Factors) is used to characterize applications as High or Low risk regarding potential exposure of protected student name data.

Access Requests and Approvals

The process of granting access is as follows.

  1. Client reviews directory info, if necessary gets support from C&C on determining needs.
  2. Client self-identifies its type, and requests access to selected attribute sets from C&C directory support.
  3. C&C DS verifies type, does any other needed vetting (e.g. verifying originating department approval of request).  C&C DS also obtains information to support characterizing the client as High or Low Risk, and makes this assessment.
  4. If requested attributes are covered by blanket approval for client's type, and the client is Low Risk, access is granted.  Otherwise, the full-review process is invoked.

The full-review process permits a client to request access to attribute sets, or to individual attributes, outside of the blanket approvals.  It also permits High Risk clients to get explicit approval.  Each request will be individually considered by C&C DS.  Note that the directory must be prepared to support per-attribute access granularity.

Blanket Approvals

UW Central Business Unit Applications have blanket approval for Basic, Employee, and Alumni/Development.

UW Departmental Applications have blanket approval for Basic and Employee.

All other clients have no blanket approvals, hence must use the full-review process. 

If other common client types emerge, they can be defined and new blanket approvals sought.

Handling User-expressed Access Control

A student can indicate that their student directory info not be published, as can an employee.  This results in setting the "publish" flag in the relevant attribute sets to "no publish".  Applications that have access to the student or employee attribute sets have access to the value of the flag and to the not-to-be-published attributes.  Applications that have access only to the Basic attribute set can see a rollup Publish attribute (uwWPPublish).

Guidelines are provided for applications regarding proper handling of data when the publish flag is set to "no publish".  For example:  application functions that show data to the authenticated user may show not-to-be-published data, but application functions that show data to others should not.  See Directory Data Sensitivity Guidelines.

  • No labels