foo for thought

There’s lots of amazing technologies that have been introduced in recent years, many of which I don’t feel have had enough exploration into. As I sit in the DMV for what feels like hours, I couldn’t help but wonder why we still use the same SSNs we did from before cell phones existed. Today, I’ll explore a potential option I’ve had in the back of my head for a while – decentralizing the idea of identity, a much more secure method for identity verification.

Problem

Centralized identity opens itself to a slew of problems, all centered around identity theft. Identity theft shouldn’t even exist with the insane amounts of technology we have to our disposal. The blockchain and decentralization would solve this issue by issuing a decentralized provider for identity.

Social security numbers are also cumbersome to keep track of. Social security cards can’t necessarily be carried around, and many modern W2s don’t even show the full SSN anymore due to security concerns. To put it simply, it’s time for a system that doesn’t put your entire life into a 9 digit number.

Solution

Currently we have the social security number system. Each number is uniquely identified and uniquely assigned to each individual. With the blockchain, we could cryptographically “wrap” each SSN, needing the cryptographic private key in order to authenticate. This private key would come in the form of an app, which would give the user access to their social security number, and the method of verification would then be executed to authenticate the individual.

Organizations would be able to require this more “secure” method of verification, while still being able to access the social security number. The flow would operate as follows:

• The user requests access to something that requires their SSN. The organization requires this more secure form.
• Instead of the user handing over the SSN, the organization would initiate a transaction through the blockchain, requesting the user’s social security number.
• On the user’s app, they could verify the transaction and approve the organization requesting access to their identity.

Because this is an addition to a SSN, SSNs would still exist and be provided to each user. This also allows for a smoother rollout of the system, as organizations can individually choose if they want to “opt-in” to the more secure system.

This system successfully solves the issues mentioned above. Because data is cryptographically secure and only able to be confirmed via private key (which is, the user’s device), only the user themselves can authenticate requests, not just anyone who has your SSN.

Why the blockchain?

The blockchain ensures that the data is secure and uniquely verifiable by the entity that needs (aka the individual). Only the individual has access to the private key, which means not even the centralized agent (the SSN provider, the government) would be able to access or manipulate the user’s identity. This provides a level of security unparalleled to anything that currently exists.

The blockchain also stores a record of all transactions performed on it. Meaning, there’s a decentralized concrete record of every time someone asks for your identity.

Consumer app

This idea relies on the extremely realistic premise that everyone owns a cell phone. The only user flow that occurs is when identity from the user is requested. There, they can see who requests the identity, and have the option to confirm or deny the request (which in the backend would be a blockchain transaction).

The app would be authenticated with Face/touch ID on every instance of app leave to ensure that even if a phone is stolen, the data is secure.

Organization app interface

When an organization would like to confirm someone’s identity, they would type in the social security number of the requested person. This would associate with a person’s physical device if it exists, and ping the person’s app to confirm the transaction.

Pitfalls

Due to the nature of authentication, a breached authentication would lead to a breach in identity. This is why the system can’t operate with a generic username/password system, or even an SSO authentication method standalone. SSO also raises additional security concerns, with the provider theoretically having access to identity. Even with the 2FA implemented, hacks can still happen.

---

I hope a system akin to this eventually sees the light of day. Maybe I’ll be the one to implement this, but for now at least I have my thoughts in order.