Provisioning Person Records

The purpose of this document is to discuss methods of provisioning person records in the Registry.
When reading this document it is important to distinguish between a UUPID and a person record.
A UUPID is an attribute of a person record.
A person record in the Registry can exist without a UUPID, but a UUPID cannot exist without being tied to a person record.
A person needs a UUPID to access services; it is part of their credential.

The process of provisioning a person record at Virginia Tech currently requires a strong affiliation to the University.
Students, Employees, and Alumni all exist in Banner and their records replicate to the Registry.
Once a person's record exists in Banner, an eligible individual can create a UUPID in the Registry.
The Registry is the system of record for a very small number of attributes:

• UUPID
• Password and self-service reset data
• Affiliations
• Email Addresses/Aliases/Forwards
• and Other contact information for online systems

Banner is the system of record for all other attributes.

• People with very little or no affiliation to the university need to create UUPIDs to access services.
• Allowing anyone to create a UUPID puts applications at risk who do not use authorization.
• Allowing anyone to create a UUPID will undoubtedly lead to dirty data in the Registry.
  • With the schema changes proposed in the design section, I don't believe this is true anymore. — dfisher@vt.edu 2005/05/09 17:14
• The Registry is designed to provision person records, not UUPIDs. If you provision a UUPID, you must provision a person record.

This solution allows anyone to create a UUPID.
A weak affiliation means that the university's enterprise database houses little to no information about the person.

The major problem with a system that provides both weak and strong affiliated people is the process required to move people between these two states.
This problem is complicated even more by the fact that the current production system only provides for strong affiliations.
Any solution must have minimal impact on the current state of affairs.

• a new unique identifier must be created in parallel to the UID, called the RUID.
  • the RUID functions exactly the same as the UID in all repects except for one, it is revokable.
  • people who have weak affiliations will have RUIDs, not UIDs.
  • the RUID number space should be separate from the UID number space to reduce confusion.
    • the RUID number space may even be negative.
  • if a people record moves from weak affiliation to strong, the RUID is revoked and the UUPID is moved to the UID.
  • no consideration is given to people moving from a strong affiliation to weak as the UID is not revokable.

Current VTPEOPLE Schema:

Future VTPEOPLE Schema:

With the new schema a record in VTPEOPLE must have either a UID or a RUID, but never both.
In addition, weakly affiliated people won't have empty data fields as they have all been moved to support tables.
All Banner specific fields have been out of the VTPEOPLE table.
Weakly affiliated people can also have all the attributes associated with strongly affiliated people as the support tables, such as NAMES and EADDRESSES, reference the VTPEOPLE_SEQNO, not the VTPEOPLE_UID.

• A publically available web application allows anyone to create a unique UUPID, which has no affiliations.
  • the provisioned record would get a RUID, it may only contain data which the Registry owns.
• The user would then have to gain access to applications via some application specific process.
  • this process either assigns affiliations to the UUPID, puts the UUPID in a group, or provides more granular permissions.
  • depending on the power of the affiliation, this process may require human intervention.
  • applications must decide what affiliations they require.
• If the person's affiliation grows stronger with the University such that a Banner record is created, then the person may complete a mdsAuth like process which associates the person's UUPID with the Banner record in the registry.
  • when a Banner record is added to the registry a UID is created.
  • this process may remove the record which contains the RUID.
• If the person's affiliation remains weak and activity remains nonexistent for a certain period of time, the UUPID associated with the RUID record should be marked as EXPIRED.
  • activity would be defined as successful authentications.
    • no process currently exists for this, but a design exists and implementation would not take long.
  • whether the user would be able to unexpired the record has not been determined.

• We do not have to design, implement, and maintain UUPID generation processes for VCOM, alumni, DPIDs, etc.
• We can retire the current Pidgen code base.

• (possible con) Service providers might need to adjust their services to an environment in which one user can have more than one UUPID. Right now, everything is engineered to resolve a UUPID to a UID.
  • true, but at least we provide a method for people to keep the same UUPID as their relationship with the University changes. — dfisher@vt.edu 2005/05/07 16:18
• The UUPID namespace may shrink rapidly.

• Groups system
• Authentication tracking system

these systems would benefit from a weak affiliation solution.

Prospective employers, admissions officers, and accreditation officials might want access to student portfolios.
Some of these accounts might have limited life spans (particularly prospective employer access).

Financial institutions might need access to user-authorized data for employees such as pay rate and job history.
These accounts would likely be granted to individual representatives of financial institutions for limited period of time.

Parents, relatives or employers may need access in order to pay tuition and fees for a student.
Infinet may offer a solution to this problem in the form of pay accounts, but the university may wish to offer accounts to these users for other purposes in addition to fee payment.

Remote collaborators on open source projects may need access to local code management repositories.
A staff member of the Web Hosting group is using a special subversion instance specifically for collaborative development projects.
Other IT staff across campus may be interested in initiating or participating in similar activities.

Friends, relatives, and other acquaintances may want access to published, restricted Web content on a local Web site hosting service.
Filebox currently supports users without UUPIDs by allowing filebox users to create accounts for those users.
The account ids take the form of filebox.username.

Accounts to enable access for non-VT people who want to access content within an institutional repository.
Default system behavior for Dspace, as an example, is to offer the user the opportunity to create an account based on an email address.

Accounts for remote researchers to give them the ability to access locally managed collaborative environments, such as sakai.
Default system behavior for Sakai is to offer the user the opportunity to create an account based on an email address.

Temporary wireless network access accounts for non-VT affiliates.

This solution requires a person to authenticate themselves with demographic data before a UUPID can be created.
(Implies a Banner record already exists for the person.)
This is the solution we have now.

• It seems like many of the problems with expiration, UUPID namespaces, and the like can be mitigated by forcing a “subscription” for a UUPID with a weak or tenuous affiliation with Virginia Tech. In such a model, expiration dates would be forced on UUPID creation and it would be required for a user to re-subscribe before this date in order to keep their UUPID. After that date (and perhaps after notification by email), the UUPID could be put back in the namespace for use. This would limit the amount of clutter in ED while still allowing quite a bit of flexibility. — dhawes@vt.edu 2005/04/21 11:49

• I like Dave's suggestion of the subscription. I'm not sure if includes leveraging password expiration to prevent widespread usage of the “unaffiliated” UUPIDs. We could:
  1. Generate all new uupids with expiration dates and expired passwords and update the authentication mechanism to recognize expired passwords.
  2. Allow authentication to the affiliation generator with expired password, providing the password is correct.
  3. Password change tool could allow users with expired passwords to change to a permanent password if an affiliation exists or if the uupid is a member of a group. — dunker@vt.edu 2005/04/29 09:48
• “Person records” rather than “people” could help us better understand “duplicates.” We will always have duplicates in the sense that two records may well pertain to one natural person. However, until the university knows that multiple records refer to one natural person, there is no basis for thinking that the person records refer to anything except separate people. — srb144@vt.edu 2005/11/22
• “Weak affiliation” is defined as a relationship in which the university has little info about the person. It can be arguable whether the relationship itself is strong or weak, but the data behind the relationship is weak. — srb144@vt.edu 2005/11/22
• I'm not sure if anyone has pursued the idea of using a negative number for the RUID and whether or not it might break applications. While I initially thought the negative number was a slick solution, it may not buy us anything over just reserving a certain numeric range for RUIDs. Identifying applications and asking users to test the negative number implementation might be more trouble than it's worth. — dunker@vt.edu 2005/11/30