The Unique Identifier, AKA the Unique ID, the UID, the Enterprise Unique ID, the Primary ID, the Global Unique ID.
The UID is the key internal identifier, potentially used for authentication, authorization, group membership, and tracking (reporting, logging, auditing). It is recommended to have this ID be unfriendly so as to discourage its inappropriate use. This ID is centrally provided, perhaps through your Identity Management solution, and should be assigned to all current active users and future users. The UID should be non-revokable and non-reassignable; hence it needs a large enough capacity to sustain generations of UIDs . All other identifiers should be either directly or indirectly linked to the UID.
Now as to why you shouldn’t let users select their own ID:
- The first mistake users make is using Private Data when creating their ID (such as):
- First and last name
- Phone numbers
- The names of parents, children and siblings
Many governance rules for applications specifically disallow Personal Identity Data and this most likely would need to be coded in your IdM application and you would not be able to prevent it in the case of someone using SSN when you are forbidden from asking for SSN in the first place and this is a really, really long run-on sentence 🙂 .
- Some users will use derogatory and/or inflammatory language in their name (which may cause an issue with your support staff/help desk). I mean let’s face it, there are a lot of geniuses in the world who think Bizhatch is a cool user ID.
- As a fix in your Identity Management process, might I suggest adding a forgotten user name Use Case into your requirements so as to avoid the issue of the user having an inaccessible ID as they can request the user name be sent to their registered email address.
- If a user name is selected by a user, and the user name already exists, the new user will now “know” an existing user name in the system.
This presents an associated issue of “guess the password” in which someone selects a user name/password combination such as userID: Minnesota password: Twins. While you should have password rules to help offset this, the above example might just work.
- I would highly recommend NOT using email address as a login credential in the future as you cannot guarantee uniqueness and a family could all use the same ID (ex. RossinFamily@ThisIsNotUnique.com). Additionally if someone uses an address they no longer have you have just added to the complication (“oh yeah, I registered with my Mickey D’s email address, too bad I got fired for embezzling, maybe I should have though ahead”).
Technologically why not:
- You must code validation rules if rejecting special characters in the name (O’Rossin, R@isen, Van Rossin, etc.) and worse if allowing them (such as remove the ‘ from O’Rossin and make it ORossin, join Van Rossin into VanRossin, etc.).
- If the user can select User ID, you will have to decide if it should be case sensitive (which I would hope not as the volume of help desk calls will sky rocket) as a user might pick a name they wish to be case-sensitive (ex. ToddRossinRulez)
All in all, this list, while not being complete by any stretch, should give you some ammo as to not allowing a user to select his/her own ID.