In rigorous use in security, identification just means unambiguously referring to a specific identity. This is as simple as providing an identifier. Which the social security number roughly does (they can be re-used after death apparently).
Actually proving the provided identity is your identity is authentication. SSNs come with no decent authentication method. Hence, the identifier of an SSN is not very good in situations where authentication is required.
For an example where authentication of identifiers is not required. Consider the following: "Dear business please identify all your employees so we can correctly give them benefits". In this case, having identifiers for people is sufficient.
Heck, any case where you are asked to identify a 3d party cannot require authentication.
Strictly speaking "please identify yourself" means please give me your name. If this is spoken by someone with authority they may want prove of that claim. In that case, it is great if authentication of your given identifier is possible.
So if you have one, they are a unique record - a primary key in a database for example. It can be changed, but far less likely than a name change, and unlike names it is unique.
For the US, that sounds like a perfectly good guid to use in situations where a name isn't good enough (There's more than one John Smith in the US). The company authenticates your identity SSN with you via some means other than you telling them, you authenticate with the government via some means, and job done.
The problem is that the authentication bit doesn't exist. It's basically 0-factor authentication.
Technically there's a trivial solution -- assuming the government can authenticate a person's SSN (which they do when tehy are given out), then at that point the person gives their public key to the government, and this is stored in an open database against the guid. That means anyone needing to authenticate their SSN could simply use their private key to do so.
In reality those private keys would of course not remain private, so it's not a good solution, but it does highlight how an SSN could be used.
Even with a secure SSN, that number should only be collected by a company in limited circumstances -- you shouldn't collect PII unless you have a legitimate need, be that a name, phone number, or SSN, and you shouldn't keep it for longer than you need to. In some countries that's a legal requirement, but it's always the morally right thing to do. If you need to communicate with the government about a person, then sure, collect their SSN. If you need to know where to ship their order, then sure, collect their address.
That doesn't mean the address or SSN should be considered secure.
In rigorous use in security, identification just means unambiguously referring to a specific identity. This is as simple as providing an identifier. Which the social security number roughly does (they can be re-used after death apparently).
Actually proving the provided identity is your identity is authentication. SSNs come with no decent authentication method. Hence, the identifier of an SSN is not very good in situations where authentication is required.
For an example where authentication of identifiers is not required. Consider the following: "Dear business please identify all your employees so we can correctly give them benefits". In this case, having identifiers for people is sufficient.
Heck, any case where you are asked to identify a 3d party cannot require authentication.
Strictly speaking "please identify yourself" means please give me your name. If this is spoken by someone with authority they may want prove of that claim. In that case, it is great if authentication of your given identifier is possible.