Choosing Identifiers for Your Application

PVI? NetID? Emplid? ePPN? Campus ID? Email Address? OH MY! Help for applications looking to choose an identifier for use in applications.

A note on access to data: some of the data elements discussed in this document may not be immediately available to your application and are not publicly available by default. University of Wisconsin related applications can request access to attributes from NetID Login (and other systems) through the Identity Data Integration (IDI) request process. Note that this process does not always have to end with actual access to data and is a great place to start if you don't know where to start in integrating your application. Operators are standing by.

The choice of an identifier for you application may be something you can do something about, and it may not. Unfortunately, many applications are stuck with the things they understand and how they understand them, so you may simply have to bite your lip and work with what you have. Hopefully even if this is the case, this document can help you work through issues.

First, it is important to understand that there is no identifier that you can get from anybody that cannot and will not for a person. Anybody who tells you they can accomplish this is selling you something that doesn't exist. But, you can pick identifiers and use strategies that will enable you to have something that is more stable for particular uses, or allows you to more easily handle changes (programmatically or otherwise).

Second, there is no right answer. There may be answers that are better or worse for a situation (and answers that are definitely not going to work), but most options will work somehow.

Is there something you think is missing here? Do you have a question you'd like answered? Please comment on this doc and ask! We'll do our best to answer.

So, what options are there?

PVI

UW-Madison's Identity system's generated identifier. This identifier is issued by UW-Madison's identity management (IdM) system (Person Hub or UDS -- among other names) to what it thinks is a single person. If what you know to be a single human being has "multiple PVIs" the IdM system doesn't realize that they are one person. This problem needs to be resolved by linking the disjoint identities before the person's digital experience will function well. PVIs change regularly as new data is introduced and linked to the identity.

Pros:

  • Every person in the identity system has one.
  • Not personally identifying (not name-based)
  • Change sequence is well defined and easily evaluated going forward or backward.

Cons

  • People do not know and are not expect to know what their PVI is.
  • Changes regularly, usually for reasons the person is unaware of.
NetID

NetID is a branding for UW-Madison's login ID for people. People log in to NetID Login and other NetID-enabled applications using their NetID and password. Usernames and passwords at other institutions (eg UW-Whitewater or University of Chicago) are sometimes also called "NetID" but are not the same value and cannot be used the same places. NetIDs are generated when someone goes through NetID Activation and are not assigned ahead of time. A single individual should never have multiple active NetIDs, and it is not desirable (although it is sometimes inevitable) for someone to knowingly have multiple NetIDs at all. NetIDs are fairly stable for applications to use when identifying users.

Pros:

  • Changes more predictably for a person. NetIDs only normally change when a person asks that their NetID be changed, and the person is expecting that some services may have problems when they are changed. NOTE: it is not normal for a NetID to change unexpectedly. If this happens something has gone wrong and the user needs to contact the Help Desk.
  • Human readable, and known to the person. People are aware of what their NetID is and are not going to be offended or confused when they see it.

Cons

  • Changes are not easily followed going forward or backward. When a NetID changes the old NetID ceases to exist and a new one suddenly exists.
  • NetIDs do not exist until the person activates one. A brand new person will not have a NetID and cannot be identified using it until they go through the activation process.
eduPersonPrincipalName (ePPN) or userPrincipalName (UPN)

ePPN (also known as UPN in Campus AD) is a standard part of the eduPerson schema that identifies a person at a campus. For UW-Madison is it always NetID@wisc.edu, and as such behaves exactly the same as NetID. If your application has even the slightest chance of wanting to interact in a Federated world and incorporate people from other UW System or worldwide institutions, ePPN is the best option, as anybody logging in through SAML Federation (through Wisconsin Federation, Incommon and EduGAIN) worldwide will have one and it is guaranteed to be unique.

Emplid

Emplid is the name of the internal identifier in a PeopleSoft system. Every PeopleSoft System has them (eg, HRS, SIS, UW Health), and they are not the same across the systems. Using a particular system's Emplid will limit your application to only function with identities from that system, and is not recommended, even if your application right now interacts only with a specific backend. However, if your application does deal only with people from a particular backend system, using and tracking this identifier may help your application weather changes in other identifiers.

Campus ID

There is no common and settled definition for Campus ID at UW-Madison. There are contexts where various 10 or 11 digit numbers are used for specific purposes. See below for help thinking about how you might use Wiscard, SIS Campus ID, Wiscard Account Number, or Library Patron ID, but bear in mind that they are specifically created for specific purposes and you probably do not want to use them. . Please do not try to use these identifiers without a careful understanding, and full understanding of these is beyond the scope of this document.

Wiscard Number
The number currently printed on a non-expired or revoked UW-Madison Photo ID Card. It is 11 digits long and consists of the Wiscard Account Number and an issue code. When a card expires, is reported lost or stolen, or otherwise revoked, this number does not exist. This number will only change when a person gets a new card printed at the Wiscard Office.
Wiscard Account Number
The number designating a user's account for charging to his or her Wiscard. This is 10 digits long (does not include the issue code because it does not indicate the card). When a person has never had a card this will be the same as a Predicted Photo ID, but if the person has a revoked, expired or otherwise invalid Wiscard, the person will not have an account number and cannot charge items.
Predicted Photo ID
The number that will be printed on a person's card if they are eligible to get a card and go get a card. This can change at any time as new role data collects on a person. This number does not exist when someone has a Wiscard Number.
Library Patron ID
The number used by the UW-Madison Library to identify a patron. It is 10 digits long and usually in line with other IDs, but behave as desired by the library.
SIS Campus ID
The number issued by SIS for a student. This number will be chosen as when a new Wiscard is printed for someone who is active in SIS.

Please have an internal ID!

If possible, applications should have their own internal identifier and track PVI as well as another identifier (eg NetID) for a person so that the application can as easily as possible detect changes to it's primary identifier and recover gracefully, either by seeing that the one identifier did not change, or by evaluating changes to PVI. Tracking against an internal identifier will allow the application abstraction to recover from situations where what the application thought were two people suddenly become one (necessitating picking a "winner") or when what the application thought was a single person becomes two.

But what about email address?

We know that everbody does it, but on the UW-Madison campus, email address is a very unreliable and insecure identifier. For various reasons (that we know are erroneous, but are nonetheless real), email address is often user-provided and not confirmed. As such, if you restrict something to rebecca.blank@wisc.edu and look for that value in mail as delivered from NetID Login, it is trivial for someone to intentionally or unintentionally get in as that account.

Additionally, for the same (in this case good) reasons (especially that mail is meant to convey the address at which a person wants to be emailed), it is trivial for a user to change the value of mail to whatever he or she wishes. If your application is keying on rebecca.blank@wisc.edu and she decides she would rather use becky.blank@wisc.edu (incidentally -- not the same human being, see above about how any address could be entered by accident), she would be locked out of your application.

What about netid@wisc.edu? Isn't that a valid email?

Using ePPN/UPN (netid@wisc.edu) as an email address is a tempting solution to the problem of knowing the owner of an email address, which it actually does do. However, it only works this way for people who have UW-Madison Office365. For other people (former employees, applicants, UW System employees, UW Health and most other affiliates) who have NetIDs but are not eligible for Office365 email to netid@wisc.edu will bounce.

Regardless your population now it is not recommended that you do this, since it will bind you in the future, and you are depending on someone else's eligibility: If you decide to expand your population, you will have backed yourself in a corner and need to re-engineer; worse, if UW-Madison decides to change the population that is eligible that is eligible for Office365, your application may unexpectedly break.

How can I use email safely?

Aside from ePPN as email (above) and it's extreme caveats, the only way to use email safely is as a way of contacting the user, while using NetID, PVI or another identifier for the person.

If appropriate, use invites to a Manifest group and release that group to your application for authorization or use that group to drive a feed. Alternately, your application could issue it's own invitations to people and have them log in using their NetID (and the application uses NetID, PVI or another identifier for the person.)