User Identifiers for UCTrust

(DRAFT - 7/25/2007)

Background

UCTrust supports a variety of identity attributes that can be used by applications as user identifiers, some of which are inherited from InCommon, and some of which are unique to UCTrust.  The most notable of these are:

The selection of which of these identifiers should be used for a particular application is shown in the following table. Selection is dependent on the application's requirements for provisioning of users prior to the first session ("Provisioning Required?"), the application's tolerance of duplicate identifiers for the same person ("Duplicates allowed?"), and whether the identifier must be valid for a long time or forever ("Persistence required?").

Provisioning required?

Duplicates allowed?

Persistence required?

Strong match possible?

Recommended Identifier

Example Applications

Y

Y

Y

Y


Kuali, Travel?

Y

Y

Y



HRLMS non-employees

Y

Y


Y

ePPN


Y

Y



ePPN


Y


Y

Y

UCnetID

HRLMS employees

Y


Y


Not feasible


Y



Y

UCnetID


Y




Not feasible



Y

Y

Y

ePTID



Y

Y


ePTID

Library services


Y


Y

ePTID



Y



ePTID




Y

Y

UCnetID

AYSO



Y


Not feasible





Y

UCnetID






Not feasible


The "Strong match possible?" column specifies whether it is possible to acquire SSN and date of birth from the target user community for the application (in order to assign a uCnetID).

Note that we have no recommended identifier for applications that require provisioning and persistence, and we are starting to see applications that require such identifiers. UC's new system-wide training management system is a good example of such an application.

Applications that Cannot Accomodate Long Identifiers

Other than uCnetID, all of the identifiers mentioned here can be very long. For example, if a UUID, which is typically written as 36 characters, were used for the campus part of the a scoped attribute, then the maximum length of the value of that attribute for UC Berkeley would be 49 characters (36 for the UID, plus 13 for "@berkeley.edu"). This is longer than the maximum length of a user ID for many applications, and eduPersonPrincipleName can be even longer.

Proposal

Implementation of the University of Washington's alternate implementation of eduPersonTargetedID (or waiting for it to become part of the standard Shibboleth distribution) should give us a fairly complete set of identifiers that can be used by applications within UCTrust, except for applications that cannot accomodate long identifiers.

It is strongly recommended that applications be designed or modified to accommodate identifiers of arbitrary length, at least 100 characters. A convenient work-around to accomplish this for an existing application is to add a front-end to the application's normal authentication that maps a UCTrust identifier to the application's native identifier.

Recognizing that migration to long identifiers will not be trivial for many applications, however, a new attribute, uCTrustCampusIDShort, will be available for a limited transition period, no more than five years. It will not exceed 12 characters in length, it will contain only alphanumeric characters, and its persistence will not be greater than five years.  uCTrustCampusIDShort will also have the following properties: