Requirements and Approaches for a Publicly Visible Persistent Identifier for Person Entries in the Stanford University Enterprise Directory Service

Executive Summary

We are migrating our enterprise whitepages directory from Whois-based technology onto LDAP-based technology [LDAP]. We anticipate that many of the user interfaces (UIs) to the new LDAP-based enterprise directory service will be graphical (i.e. GUIs) in nature. However, character-based UIs will remain in use for the foreseeable future. For example, we intend to provide Whois-based access to the LDAP-based directory via a Whois-to-LDAP gateway.

Note that although one can argue that a common web-based GUI approach to displaying directory query result sets is as a simple textual list (perhaps tabularly arranged) in a subwindow, disambiguation between entries with identical names can be accomplished via rendering the entries using hyperlinks to further information, obviating the need for a disambiguating ancillary entry identifier. Since we plan to provide a Whois-to-LDAP gateway, we need to provide some identifier for entries which serves the purposes that the Whois handle does.

Though, the Whois handle, as instantiated in our Whois-based directory, has been problematic for users in our experience. Our Whois handles are based on peoples' names and are used strictly within the context of the directory. Since other people with similar names may arrive at the university or people may change their names, one's Whois handle is not guaranteed persist over time, i.e. it may change. But users continually mistake the Whois handles for email addresses and are perturbed when they change without their knowledge. We believe the amount of user confusion and our on-going effort to dispel it justifies looking into the issues and seeing what we can do to resolve them while we're migrating to a new technology base.

This document analyzes the requirements for the "handle" concept, which herein is termed a Publicly Visible Persistent Identifier (PVPI), and presents two solution approaches. They are summarized as..
 

A1.	Construct and utilize a guaranteed-unique form of Registered Name, i.e. a "Uniquified" * Registered Name (URN).

 
 

A2.	Construct and utilize a unique, fixed-length, non-Registered-Name-based alphanumeric identifier.

 

The tradeoffs involved in utilizing either approach are subtle and varied. They are summarized in the section entitled An Alternative Solution Scenario and Two Subsequent Approaches. The Bottom Line section summarizes the quandary, and Our Chosen Approach specifies the solution. We recommend that readers read at least those three sections. Readers interested in the gory details are invited to begin with the following section.

* "Uniquified" was first coined by Tim Howes in a message to Jeff Hodges about how they rendered people's names unique in the UMich X.500 directory service. It means, essentially "to have been rendered unique".

Document Conventions

Definitions, Background, and Motivation

A subject is a named, often real-world, entity. A person, for example. A person entry in the directory is an entry with an objectclass of "person" [LDAPattributes] which we map to a real-world subject, i.e. a person. We accomplish such mapping through the use of subjects' names and identifiers. A name is a character string that may map to zero, one, or more subjects. A natural name is a name that is based on a subject's real-world name. An identifier, in contrast, is a name that maps to exactly one subject. An identifier may be based on a subject's natural name, or it may be artificial -- a number or a bit string, for example.

We use different forms of names and identifiers in various situations depending upon contextual requirements. For example, a user interface (UI) to some application might prompt a user for their "name", and expect that most people will enter some form of their natural name. Another UI might prompt a user for an identifier and expect that people will enter one rather than their natural name. Though, there may be environments where one's natural name is treated as an identifier, but we explicitly do not encourage that approach in our environment. This is because although natural names typically map to individual subjects, occasionally some map to an additional number of subjects.

In our interwoven Stanford University Network Identifier [SUNetID], Person Registry [Registry], and Directory [Directory] environment we have defined the following types of names and identifiers...

• Registered Name -- the full, official, legal natural name a subject supplied in the act of becoming known to the university. Registered Names are often unique, but not always. Additionally, one's Registered Name may be unique within the directory at one point in time, yet not be unique at another point in time -- or vice versa.

• General Identifiers (GeneralIDs) -- a General ID is the base class of identifiers utilized in the SUNetID system. General IDs may take several forms...

 
• Registered Name-based GeneralIDs

• Other General ID forms, e.g. a DCE Universal Unique Identifier (UUID).

• All GeneralIDs are managed by the SUNet ID system, and thus are SUNet IDs.

• All person entries in the directory will have an attribute containing the subject's (not-guaranteed-unique) Registered Name.

 
• Not all person entries in the directory will have a (guaranteed-unique) General ID attribute.

Some UI scenarios for directory queries require selection by the user of particular entries from a set of returned, and often summarized, entries. Examples of this arise with "whois" and "finger" command line-based UI "frontends" to the directory. With these UIs, it is typically up to the user to enter an identifier from the first result set in order to obtain a complete view of a single entry . Other examples arise in the context of graphical UIs (GUIs) to the directory. Here, though, the GUI can hide from the user the unique identifier used to make the singular selection from the original result set.

Currently Recognized High-level Requirements

Another clear requirement we've derived over the years of running the Whois-based directory service is that subjects would prefer it if all things in their entries smacking of "names" or "identifiers" would only change if they perform some explicit action that reasonably causes them to change. E.g. by changing their Registered Name. This of course occurs "natuarally" through various life changes, e.g. matrimony.

The third requirement is one of consistency -- the style or form of the human palatable identifier should be the same for all person entries. Our experience suggests that user and subject confusion will result if there is not a consistent form of human palatable identifier across all person entries.

The fourth/final requirement is that this identifier must be visible to all directory clients whether they are authenticated and authorized or not -- i.e. it must be "publicly visible".

The Problem Statement

• What do we use as a publicly-visible, consistent, not arbitrarily changing, human palatable identifier for all person entries in the directory?

Note that we're explicitly not using the term handle in this document in order to avoid confusion with the particular-to-Whois instantiation of this concept.

Detailed Technical Requirements

• A PVPI MUST be unique within the set of all PVPIs in the directory at PVPI instatiation time, and on into the future.
   
• An entry MUST have at most one PVPI.

 
• A PVPI MUST be reasonably persistent.

• A PVPI MUST be reasonably typable.

• PVPIs MUST be capable of being applied to any applicable class of entries in the directory, where applicable classes MAY be drawn from: classes and departments, if they are present in the directory and generally visible to ad-hoc users.

 
• Each applicable entry MUST have one.

 
• PVPIs MUST be generated without requiring input from the subject.

 
• A requestor MUST be allowed to retrieve the PVPI attribute if the requestor may legitimately retrieve any portion of the entry, given the requestors authorization level.

• PVPIs SHOULD be strongly persistent. I.e. the same value persists while the user is in the overall system though it MAY be changed at user request, if supported.

 
• PVPIs [ MUST | SHOULD | MAY ] [ not ] be reassigned. I.e. the PVPI for one person is [never | might be ] used for another.

 
• PVPIs [ MUST | SHOULD | MAY ] [ not ] look similar to a person's name, even across name changes (so the PVPI is familiar). This requirement conflicts with the persistence requirement, and, for long names, it may conflict with length requirement.

 
• PVPIs SHOULD be easy to remember. I.e. they are name-like, or similar to some other attribute, e.g. uid (nee userid, neeSUNet ID), or simply short, e.g. 7 or 8 digits.

 
• PVPIs SHOULD work with command-line-oriented Whois- and Finger-based gateways to the directory. I.e. there's no embedded whitespace or UNIX/DOS shell metacharacters in the PVPIs.

 
• PVPIs [ MUST | SHOULD | MAY ] not have any conflicts with SUNet IDs. I.e. a PVPI can be the person's SUNet ID, but should never be someone else's SUNet ID.

 
• PVPIs SHOULD reuse existing identifiers if possible. There's no reason to invent new ID space for this modest purpose if another one will do, e.g. SUNet ID for those who have them.

 
• PVPIs SHOULD be consistent across all entries. This is so PVPI users will have a more consistent user experience.

 
• PVPIs SHOULD be unique across all commonly-searched attributes. E.g. "hodges" or "morgan" are a poor choices since they match many people's last names -- and last names, as embodied in the surName (sn) attribute, will be commonly searched upon, as will commonName (cn) which contains fullnames and thus surnames.

 
• PVPIs SHOULD not be easily confused with other ID-oriented attributes. E.g. "whois handles" look like login IDs, but aren't. This can be quite confusing and a Bad Thing when someone's handle is someone else's ID. Additionally, an all numeric PVPI might be confused with a phone number, or a University ID number, or even a zip code.

Readily Apparent Solution Scenarios and their Issues

An Alternative Solution Scenario and Two Subsequent Approaches

Should PVPIs be "name-like"?

• They must be alterable as a person's name changes.
• They should be alterable to meet the person's desire for what their name should look like.
• Their use and management overlaps so much with SUNet IDs that it is obvious just to make them be SUNet IDs, with the uniquified Registered Name as a default long-form SUNet ID.

• they should be short numbers, with..
• some distinguishing look so that they aren't likely to be confused with University ID numbers, phone numbers, Zip codes, or some other relatively pervasive, short number in our lives.

In summary, the two approaches are..

A1. The Guaranteed-unique Form of Registered Name Approach

• Construct and utilize a guaranteed-unique form of Registered Name, i.e. a Uniquified Registered Name (URN).
• Form would be "Registered Name with a number at the end".
• The URN is managed as a SUNet ID to ensure no conflicts.
• The URN can be used just like any SUNet ID, e.g. as a SEAS alias.
• URNs will change automatically as a user's Registered Name changes.
• The user can choose to make the PVPI be some other SUNet ID.
• The PVPI can change at the user's request.
• A PVPI is non-reassignable.

A2. The Fixed-length Non-Registered-Name-based Alphanumeric Identifier Approach

• Construct and utilize a unique, fixed-length, non-Registered-Name-based alphanumeric identifier.
• Assigned by the Registry.
• Short, for ease of remembering and using.
• Alphanumeric, in order to avoid confusion with Univ IDs. Perhaps the alpha portion should be fixed in order to aid the point above. E.g. DS1234567
• The ID is permanent, non-re-assignable, and non-changeable.

Implications of Approach A1

• It has an obvious relationship to the subject since it is based upon the subject's Registered Name.
• Arguably more familiar to current Whois users, since it would be similar to current Whois handles.
• More mnemonic in general.
• Those who wish could potentially reuse an existing SUNet ID form.

• The length varies and is relatively unconstrained.
• The user is exposed to the management of the PVPI.
• There will be many more entries in the SUNet ID system.
• Possible confusion with auto-generated SUNet ID PVPIs mixed with user-chosen ones.
• Not consistent across all entries.

Implications of Approach A2

• The length can be constrained.
• Consistent across all entries.
• Essentially no additional UI required in the overall Registry/SUNet ID/Directory system.
• No changes ever, period.

• It will not necessarily have any obvious relationship to the subject's Registered Name. I.e. it is not mnemonic.
• Confusion due to people having yet-another-number to deal with.

The Bottom Line Decision...

A2 is much easier to implement, but may not be as palatable.

Though, can we afford to do A1; is it worth the effort?

In the next section, we discuss and specify the approach we decided to implement.
 

Our Chosen Approach

Here's the format we chose for the PVPI...

• "DS" represents a 2-chacter alphabetic, fixed upper case, substring, i.e. [A-Z], with the constant value of "DS" for now, but we may add other values in the future.

 
• "nnn" represents 3-digit numeric, i.e. [0-9],substrings, which are randomly assigned, rather than serially.

 
• "A" represents a single-character, fixed upper case, alphabetic substring, also with randomly assigned values, from the set [A-H, J-N, P-Z]. Note that "I" and "O" are excluded in order to eliminate potential confusion with "1" (numeral one) and "0" (numeral zero).

DS468J135

• Entirely unlike a spoken or written "word",
• Largely unlike a phone number (at least in recent times, in this country), University ID number, Zip code, car license plate number (at least in California), etc.
• Relatively easy to remember,
• Fixed length,
• Scalable to millions, but not billions or more.

Conclusion

Appendix A

References