A Texas A&M University System Office of Information
Technology White Paper
Introduction
This paper defines the UIN digital identity as used by The Texas A&M University System and its member institutions and agencies, establishes what a UIN is and is not, and documents the UIN’s role in identity and access management (IAM) within the A&M System.
For a brief primer on digital identity, see Appendix A.
Document History
| Author | Date | Notes |
| Marc Moore | 7/10/2024 | Initial version |
UIN Definition
The UIN is a system-controlled digital identity that plays a major role in individual and federated identity and access management across the A&M System.
UIN is the common acronym for Universal Identification Number at the A&M System. UINs were established in 2003 with the goal of uniquely identifying people in the system’s technology systems, eliminating the use of the Social Security Number (SSN) as an identifier, and to provide improved privacy for individuals and better conformance with federal laws regarding use of the SSN.
UIN Systems
The UIN Systems are a set of applications operated by The Texas A&M University System’s Office of Information Technology (TAMUS OIT). The primary components of the UIN Services are the UIN Manager web application used by administrative personnel to create and manage UIN identities and attributes and the UIN Services REST APIs used by technology systems to create, manage, validate, and obtain UIN identities and attributes. The core of the UIN Systems is the UIN Master data store, a centralized database containing all UIN identities, attributes, and history.
UIN Format
The UIN is a 9-character, fixed-length, alphanumeric field. To-date, all UINs issued are numeric, with 0 in the 4th and 5th positions in the string. As of July 2024, approximately 36% of possible numeric UINs have been issued.
The UIN is expected to remain in place as the A&M System’s common identifier. Therefore, considering the current rate of consumption, TAMUS OIT expects to begin issuing UINs with alphabetic characters in positions 4 and 5 sometime after 2030.
What the UIN Is
A Human Identity
The UIN is an identity for internal users (employees) and external users (retirees, terminated employees, customers, consultants, vendors, and partners). A UIN is established by the assertion, validation, and acceptance of other intrinsic and assigned attributes. Some of these may be “proven” by physical identity documents such as a Social Security card or birth certificate.
UIN Attributes
The primary data attributes of the UIN are:
- Full Name
- Date of Birth
- SSN
- Sex
- Student ID
- Country of Birth
Secondary attributes include:
- TAMU Card ID
- Good “Replacement” UIN
- Comments
- Added Date/Time
- Added By ID
- Updated Date/Time
- Updated By ID
- Systems Using Reference (array)
The UIN Master data store also contains a full change history.
Identity Key
The UIN is a key identifier in the larger identity and access management and service provider landscape. Within the scope of its stored attributes, UIN Services offers identity-as-a-service, allowing relying parties to validate or obtain UIN attributes to which they are authorized.
Authentication
Systems can (and should) use the UIN as an attribute of user records in application domains, particularly for use in authentication.
Compared to application domain custom identifiers, the UIN provides many more opportunities to leverage existing identity data and authentication services such as the TAMU Federation and TAMUS Single Sign On integrations.
Authorization
The UIN may be used in authorization as a key for role authorizations, with the caveats that an individual’s UIN can change. The UIN enables authorized transactions within and between systems without exposing private data elements such as SSN.
As one example, TAMUS Single Sign On uses UIN as the identity attribute on its role authorization records.
Because it is possible for an individual’s UIN to change, systems utilizing UIN as an authorization attribute should ensure they are able to be responsive to such events and implementing reactive processes accordingly.
Service Provider Identity
Many domain-specific applications use the UIN as a key value upon which other attributes depend. For example, Workday uses UIN as a key identifier of its employee records, the employee ID. Across the A&M System, dozens of applications do likewise.
What the UIN Is Not
Non-Human Identity Support
The UIN identifies employees, students, and other individuals who have a relationship with the A&M System. It does not act as a service identity such as:
- Corporate identities – universities, government agencies, corporations, partnerships, and trusts
- Workload identities – software workloads such as applications, services, scripts, or containers.
- Device identities – servers, desktop computers, mobile phones, IoT sensors, and IoT managed devices.
IAM Solution
As discussed, the UIN Systems provide the UIN identity value and a limited set of associated attributes and can play an important role in the IAM space; however, they do not themselves comprise an IAM solution.
In particular, while the UIN Systems provide the foundational data element(s) for member institutions’ identity providers and service providers to validate against, they do not contain domain authentication or authorization data. Applications wishing to perform these functions using the UIN must manage that data relationship independently of the UIN Systems.
IAM and UIN
This section discusses how the UIN supports key elements of an IAM strategy:
- Identity management:
- UIN Services supports the creation and management of the UIN identifier and its attributes but does not define a person’s digital identity, permissions, or access levels in any specific domains.
- Identity federation:
- The UIN identifier is commonly used across the A&M System to allow the use of existing credentials for new services.
- Provisioning and deprovisioning
- The UIN identifier is representative of a single person, living or deceased. It has an infinite lifetime, which is different than a credential.
- The UIN identifier is not a user account. The application user lifecycle, including assigning or revoking access to resources and permission levels, is outside the scope of UIN services.
- Authentication and authorization:
- The UIN identifier is not itself a credential, although it may be used as the key in a credential implementation; e.g., TAMUS SSO.
- The UIN identifier implies no authorization or access. Validation of identities and granting authorizations and access rights is the domain of the IAM solution and/or service provider applications.
- Service Delivery
- Users must be provided with authorized services defined by the service provider, not the UIN Systems.
Summarizing the above, IAM is a solution space that is much larger than the UIN identifier. Still, an IAM solution may utilize the UIN for key portions of its function.
Immutable With Regard to Individuals
The UIN used to identify an individual can change over time, primarily due to mistakes in the issuing and management processes. Identity and service providers that rely on the UIN identity should prepare for such changes.
Operations and Adoption
UIN Operations
The UIN Systems are supported and operated by the System Enterprise Applications (SEA) department in TAMUS OIT.
UIN Manager
UIN Manager provides the user interface for administrators – primarily consisting of Human Resources personnel – to create and manage UINs for employees. It also provides screens for management of other individuals’ UINs, including students, contractors, and others.
UIN Manager uses the SSO role authorization mechanism to provide access ranging from read-only to full administrative capabilities.
Roles are granted through the SSO Statement of Responsibilities with supervisor and administrative approval required. Roles are reviewed through the SSO Role Review process and SEA reserves the right to limit access to persons with adequate justification and remove it where it has been granted inappropriately.
UIN Services
In terms of raw numbers, the UIN Master data store contains far more UINs assigned to students than it does for employees. This is because most A&M System universities assign UINs to some or all of their students using the UIN Services APIs.
UIN Services provide the following functionality:
- UIN creation
- UIN attribute retrieval
- UIN verification
Member IT departments can become a client of the UIN Services APIs by requesting access using the SEA API Developer Portal. Upon approval, partner teams obtain the necessary API credentials and authorizations from SEA, develop and test their application against the UIN Services Test environment, and are then able to move to Production.
The UIN Services APIs are RPC-style, REST-based JSON implementations.
Client Application Implementation
Service providers such as Workday that use the UIN to key data records should minimize its proliferation across data structures. The TAMUS Workday implementation does this, allowing it to adapt to UIN changes easily. Other service providers such as TrainTraq use the UIN as a key value in multiple, complex data relationships. For such applications, UIN changes are much harder to react to.
The impact of a UIN change on applications and their operational staff can be substantial. It is therefore important that human and service users of the UIN Systems take every opportunity to ensure that individuals are assigned only 1 UIN.
The UIN Services matching algorithm makes every reasonable effort to ensure that possible existing UIN matches are brought to the attention of the client during the UIN creation process. However, the limited set of attributes available to the matching function leaves considerable ambiguity. Inevitably, some individuals are assigned multiple UINs.
Most often, this can be traced back to a common cause: The user or API client does not have available or does not submit an individual’s SSN to the UIN creation process.
For the health of the overall UIN ecosystem, client applications and related business processes should be designed to capture the SSN (or TIN) of all possible individuals prior to creating a UIN. Understandably, this is not possible in every case. However, being a good citizen of the UIN community demands that every possible effort be made to do so.
As stewards of the UIN Systems, SEA may require that non-compliant service providers re-implement their business processes to better enforce this requirement.
Conclusion
The UIN is the digital identifier with the most coverage of individuals associated with A&M System institutions. To-date, it has been a simple 9-digit identifier with 0s in the 4th and 5th positions. This format will change several years from now unless a new identifier is created to replace it and, while the change is not imminent, implementers should prepare for the future.
While the UIN Systems do not provide IAM functionality, the UIN is a key identity attribute in IAM and business applications. Service providers are welcome to key user data with it but should seek to minimize the number of data structures in which it is used in the application domain.
The SEA team in TAMUS OIT supports and operates the UIN Systems, including the UIN Master data store. As such, SEA is responsible to ensure that access to the UIN Systems is limited to those individuals and systems with a business need. Similarly, SEA oversees the data quality of the UIN Master data and may require changes in client application approaches and processes to ensure data integrity.
The UIN Systems have been in service for more than twenty years and have undergone multiple technical and business changes during that time. While it is possible to imagine human identity at the A&M System expressed with a different digital identifier, it is expected that the UIN identifier will remain in place for a number of years to come.
Appendix A: Identity Background
Digital Identity
What is an identity? Whether physical or digital in nature, identity is a collection of individual information or attributes that describe an entity and is used to determine the transactions in which the entity can rightfully participate.
Identity Attribute Types
Identity attributes fall into three main categories: Intrinsic, Accumulated, and Assigned.
- Inherent attributes are intrinsic to an entity and are not defined externally. Inherent attributes for individuals include age, height, date of birth, and fingerprints.
- Accumulated attributes are gathered or developed over time and may change (multiple times) during an individual’s life. Some examples: job history, benefit enrollment, and tax withholding/status.
- Assigned attributes are attached to the person but are not intrinsic. These attributes are generally are reflective of relationships with other bodies and can change. For example, e-mail address, login credentials, telephone number, social security number, passport number, and role authorizations.
Like the SSN, the UIN is an assigned attribute – one that is established and maintained by the UIN Systems.
Identity attributes enable entities to participate in transactions by proving that they have the specific authorization required for that particular transaction. The relationship between identity attributes and authorization is a often both complex and domain-specific. For example, a Department Signer attribute confers certain privileges in Application A; however, this implies nothing about permissions in Application B.
Identity Providers
An Identity provider is an entity that holds user attributes, attests to their veracity, and completes identity transactions on behalf of users.
Common identity providers are Windows ActiveDirectory, Microsoft EntraID (often replicated from ActiveDirectory), and campus/agency authentication providers such as TAMUS Single Sign On, TAMU Central Authorization Service, and others.
Sources
WEF – A Blueprint for Digital Identity – Final Draft.pptx (weforum.org)
What Is Digital Identity? How to Create a Secure Digital ID (g2.com)
UIN Service Description.docx (tamus.sharepoint.com)
What is Identity Access Management (IAM)? | Microsoft Security