1. Introduction

The Core User Directory (CUD) contains details of every person who has a current relationship with the University. Currently this includes those who are students, researchers, tutors, staff and alumni. It is possible that as more information becomes available, CUD will also hold information about prospective students and those who registered to receive information about services.

CUD consolidates records from a number of data sources for those persons. The result of matching and consolidation is that CUD is able to provide the following key services and benefits:

CUDID, is a globally unique identifier across all the CUD data providers. This allows all data providers to have a common reference for every person record they hold. It also allows data managers to check whether a new record in their systems already exists elsewhere in other systems: if it doesn't, a new CUDID is assigned to that user for other sources to match against. The benefits of this process are that, for example, if a person returns to the University after they have been deleted from one data source, if there is a match against a historical record in another source, they can retain their old identity in that source, rather than create a duplicate record for that person.

Data Matching matches and consolidates records between sources; an outcome of this process is that source data is cleaner with no duplicate records. Should there be duplicate records CUD can provide information about multiple matches that enable records to be merged, and if required un-merged. CUD provides a set of consolidated data about a person that could not be obtained from any one other source, making it easier to query and get the desired results.

Foreign key service- this is an attribute which each data source provides to CUD for every record which it submits to CUD. It provides a reference for CUD data consumers to use to refer back to the original source, indeed to the specific record for more information. For example an ITSS officer may have been asked to provide a report on all student results over the last five years. Using CUD he can extract the FK provided by OSS and request details from OSS data manager for the information he requires. In the case of OSS of course the FK may be available from another source as it is the OSS _ID. Additionally, because the ITSS office also has the CUDID he can provide other consolidated data in the same end report for each student from other databases. Not all data providers make their foreign key available elsewhere.

Attribute release policies allow data owners to stipulate who can access attributes that are not in the CUD attribute set. Thus CUD can provide a single place for data owners to configure policies to make data available to requesters for specific data. This could be another data provider for example careers may require sensitive data from HR. This data can be controlled and made available via CUD rather than having a manually configured query.

A full service description is available on the CUD project page There are two types of CUD service users; those systems which contribute data to CUD, ie Primary Data Systems (PDS) and those system which query data stored in CUD, ie CUD data consumers.

1.1. Primary Data Systems (PDS)

PDS provide primary data to CUD; many sources store both primary data (ie. data for which they are the originator) and secondary data (ie. data obtained from another source). Secondary data may only be used for data matching; it is not included in the CUD attribute set (ie. any released attribute values).

As the diagram below shows, matching data is stored separately from the other data. The data which is made available to registered data consumers is the CUD attribute set. The metadata stored for each of attributes in the CUD attribute set will identify the origin, and value stored.

CUD attribute usage (draft)
Figure 1. The diagram shows CUD attribute Usage (draft)

Other attributes may be made available to specific data consumers using attribute release policies. These are determined by the data owners and are subject to the approval of the Governance Committee for Identity and Access Management (IAM) services. The current CUD core attributes, justification and the criteria used to determine inclusion are defined separately in the discussion document Core Attribute Set This document also specifies how to request changes to the set of Core Attributes, and details the criteria required to qualify as a PDS .

Each PDS will be required to enter into a Service Level Agreement (SLA) between the CUD service provider and the nominated PDS data owner. A typical such agreement is shown here.

CUD Data Consumers

CUD data consumers are able to query CUD data and obtain a result, or set of results, about the user records they are interested in. The data owners of CUD data consumer systems are not required to enter into an SLA, they are required to agree to the Terms of Usage and this SLD.

CUD Data Access and Flow

Data flows into and out of CUD by a number of mechanisms and protocols; these are defined here. Data Owners and Data Managers may control access to the data they store in CUD by means of an Attribute Release Policy, which they may configure via the appropriate user interface, subject to change control process (which includes the approval of the Governance Committee). Data owners and managers may request changes, subject to the change control procedures.

Service registration

Registered ITSS and nominated Data Owners are entitled to request access to the Core User Directory to become a CUD data consumer and or a Primary Data System. Following registration, data access will be granted and the data feed configured to meet the client's specification. Follow the link to the description of the registration process.

Requests to register a service user system for access to Core User Directory should be sent by email to cud@oucs.ox.ac.uk; a response will be given within one working day.

Provisioning for CUD data consumers will normally be completed within 1-2 working days of the request. The provisioning process is defined here.

PDS provisioning for CUD will commence within 1 working day. The provisioning process for PDS is defined here.

Requests for Change

Data owners and managers may request changes to the data collected from CUD and data delivered to CUD, and the means of connection. These requests are also subject to a change control process.

Up: Contents Next: 2. Summary of OUCS’s responsibilities

Sections in this document: