Other answers have addressed the main issues. There are two side issues worth noting. The first is mutability and the second is trustworthiness.
It is usually necessary, or at least very desirable, to have the primary key be immutable. If it can be modified at will, and if it's the target of recorded references, then the modification has to be cascaded to all of the references, or else references will be orphaned. Foreign keys are the most obvious case of recorded references, but they aren't the only case.
For most databases, auto-increment integers are immutable, and in cases like yours that's a plus.
Natural keys are sometimes mutable, and are sometimes used as identifiers. Many websites that support identified users use email address as the userid. This works out well in practice. Most users have an email address, they are supposedly unique, and the user can remember it. So the user references their account this way, even if the account has an internal id that is merely a meaningless number. When a user changes their email address, they are going to want to change their userid at most websites, in order to cut down on how much they have to remember. If the website won't allow that, because the userid is marked as a PK in the database, that's a data management problem.
Second, when you rely on natural data for the row identifiers, you get into trouble when they are wrong, due to error or deceit. For example, when you hire employees, there is always the possibility that you will hire someone who gave you a false social security number. If you later hire someone with that social security number, now you are up the creek. I don't know your case well enough to say whether this consideration applies here.