Identifiers

Types of Identifiers

An identifier is any token that can act as a unique reference to an object in the Registry, in this case a Person. Principal among the Person identifiers are those that the University considers shared enterprise identifiers — SUNet IDs, University IDs, and Campus Card IDs — as well as identifiers mapping between identifiers from different sources. Identifiers are for the person as a whole; the Person Registry does not have "affiliated" identifiers (identifiers tied to specific affiliations in the record).

The Person Registry supports the following types of identifiers:

A person in the registry always has two identifiers:

Registry ID

A 32-character representation of a registry-generated UUID (Universal Unique Identifier). Values are pre-generated and stored in the id_free_list table and assigned to new person entries via a trigger on the person row. The Person regid is exported as part of the person data and is a stable, enduring identifier for a person, even if other identifiers change over time. No other identifier both covers the complete Registry population and is intended by design to not change over time.

The format of a regid is equal to the hexadecimal string representation of a UUID, numbers 0..9, characters a..f, minus hyphens. Examples:

00e7e10692aa4aaf8a34ae62d7235b71
​64ec5fa6e77011d1830c2436030baa77

Directory Unique ID

A registry assigned ID in the form Dxnnnannn, where each "nnn" is a random three digit number and the "a" is a random uppercase letter except for O or I (to avoid confusion with zero and one). The "Dx" prefix can technically be any pair of uppercase alphas over time. Originally only a prefix of DS was used (for Directory Services); more recently there have been cases of DR...DZ for operational reasons, but the current default assignment range stays with the DS series. The composite value is unique across the Person Registry.

Values are pre-generated and stored in the id_free_list table and assigned to new person entries via a trigger on the person row.

This identifier is specifically created to support a directory requirement, largely needed by the whois protocol, for a human readable and easily typed public number that can be offered on a multiple-entry menu and then used in a subsequent query where there is nothing else about an entry that would make a query unique to an individual. In essence it is a public "handle" for convenience in human and automated whois interactions for uniquely keying entries in a result set. It is not meant to be used as an enduring system identifier or retained as a permanent key for an individual as there is no guarantee that the numbers will remain the same over time.

All other identifiers are optional:

University ID

An 8-character numeric ID used as a unique identifier for people across Stanford administrative applications. Univids are assigned in 2 ways:

• Sourced from PeopleSoft CS: If the person does not yet have a univid one will be created from a CS refid. If the person already has a Registry-assigned univid, the Registry-assigned univid will be deprecated and become an xunivid, and the CS refid becomes the univid.
• Sourced from PeopleSoft HR: If the person does not yet have a univid one will be created from a HR refid. If the person already has a Registry-assigned univid, the Registry-assigned univid will be deprecated and become an xunivid, and the HR refid becomes the univid.
• Sourced from the Registry: When a sponsored affiliate becomes a member of the stanford:administrative privgroup, a univid is assigned from the next available value in the Registry's univid_freelist table.

Principal ID

The primary sunetid for the individual. It is a network-authenticatable secure ID corresponding to the user's Kerberos principal and also known as a network login ID. By policy a person may only have one principal identifier which is considered their identity identifier for infrastructure/network interactions. It also is the basis for all personal account services granted to an individual, that is, the principal ID is also the users email account, afs/leland account, etc.

This identifier exists for the person "for life", that is, regardless of whether the identifier is enabled for login or whether any services are attached.

SUNet ID

A person's Kerberos principal is also their primary SUNet ID, essentially a separate expression of this identifier as a service bearing ID for the person. Besides the primary sunetid, a person with full services can have up to two aliases that represent them in email addressing and homepage URL resolution. These are collectively known as the person's sunetids.

Sunetids exist in the Person entry only when they are active service IDs.

Campus Card ID

Also known as the mag-stripe number. This is the encoded key for the card and the number used by the ID Card system to associate cards with card holders in that system.

Campus "proximity" Card ID

Campus cards that are enabled for door lock readers have an additional identifying number for that function, recorded as this identifier type. This connects IDs read by a card swipe with the card holder.

Reference ID

Source systems each have their own identifiers within their systems to uniquely identity an individual. Such a local identifier must be passed to the Registry as part of any data feed. It is the ID the registry will use to reach back to the source system, if appropriate, to fetch data. It is also a reference to tie subsequent interactions with that source system to the same individual. A source system may be using an enterprise identifier or a local ID with meaning only to that system. In principle this is irrelevant and unknown to the Registry, which simply uses such IDs as opaque references back to the source system.

Reference IDs across all source systems are not by their nature globally unique. In the context of the registry, they are unique only as a combination of source code + identifier. In the relationship table these two parts are kept as separate attributes, while in the identifier table they are combined, separate by a slash, to create a unique identifier that doesn't collide with any enterprise identifier. For example:

refid = campcomm/09123716
refid = mla/29110362
refid = hospital/pers00583163erd_5224207312040500

Other

An undifferentiated type of ID contributed by a source to augment the search space. This generally has limited use and is used to solve specific problems. For instance, the sunetid system will insert a source=sunetid, type=other ID for a pending ID -- one that has been requested but not activated -- so that person can be found by that ID during sponsorship.

General

Originally a catchall for undifferentiated IDs, it served the purpose of "other" above as well as a general bucket for previous ID values of specific types, like a former univid or sunetid. This latter function has mostly moved to specific ID types (see next section). This ID type should be eliminated.

xregid, xunivid, xprincipal, xrefid

Former ("ex-") values of the correspondingly named identifiers. These IDs are still needed in the unique ID search space to a person can be found by both current and former enterprise identifiers, in case an external system still has an older reference.

Parts of an identifier

Each name in the registry is stored as a single row in the identifier of the Registry database. An identifier consists of these parts:

Type of identifier

Type of identifier per above.

Identifier

The identifier value itself in its "external" form, that is, case and punctuation preserved as assigned by a source or as entered by the user.

Normalized value

The identifier value forced to lower case and stripped of punctuation. This value is materialized in the database itself to support normalized searching for the Document Service and RegAdmin. As an exported value it facilitates use of the same normalized values for similar search requirements in the directory in the suGeneralID attribute.

Data integration rules

Identifiers from a source to the registry

The Person Registry has a domain of expected identifier types that it will process, as determined by the Person DTD. As discussed above, there are also specific rules around certain identifier types (e.g., campcomm refids and univids). Beyond this, the Person Registry accepts identifier values as provided by the source. Syntactic rules or the number of values allowed is the purview of those external systems.

Identifiers in the registry outbound Person XML document

All identifiers in the identifier table are exported in the document. Only the regid is not include in the <identifier> element since it is already a prominent identifier at the root of the document.

Events

Registry/Directory synchronization events

The Person Registry posts an registry_person:reconcile for any change in identifier data.

Infrastructure person events

The person Slog process that maintains Person data in the Directory posts the following events when directory attributes change. The parms designating the specific data type allow consumers to filter the events to select only changes needed by their system.