Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think you're forgetting the part where those existing so-called "decentralized" ID systems are by-and-large using a centralized system (your SSN) which is magntitudes worse than a cryptographic card.

Your bank knows that you are the same John Smith as your employer has on record, because you needed to use the same SSN for both. The status quo is that any service which requires identity validation is requiring you to provide your SSN, which in internet terms is like authenticating with only a username (no password) on all websites, AND you have to use the SAME username for every different site.

Now compare that to public-key encryption. Not only is it better assuming you only have access to a single private key (because you are still authenticating with the output of the key, not the key itself as with SSN), but also because a cryptographic card could store MULTIPLE private keys, allowing you to authenticate with a different "identity" to different providers, making it impossible for them to cross-reference you in that way.



> I think you're forgetting the part where those existing so-called "decentralized" ID systems are by-and-large using a centralized system (your SSN) which is magntitudes worse than a cryptographic card.

It's orders of magnitude worse at authentication because that's not what it's for and everyone should immediately stop trying to use it for that. For that matter it would be better if they would stop using it for anything other than its original purpose as a tax ID.

> Now compare that to public-key encryption. Not only is it better assuming you only have access to a single private key (because you are still authenticating with the output of the key, not the key itself as with SSN), but also because a cryptographic card could store MULTIPLE private keys, allowing you to authenticate with a different "identity" to different providers, making it impossible for them to cross-reference you in that way.

But that's exactly the point. That isn't a national ID, it's ordinary public key cryptography which anyone can use right now already. You don't need a national ID for this, just create a new public-private key pair whenever you first interact with a new entity and use it to authenticate yourself to that entity going forward.

> Your bank knows that you are the same John Smith as your employer has on record, because you needed to use the same SSN for both.

But there is no good reason they need to know this, because having a bank account has really nothing to do with having an employer. All your employer should need is your bank account number so they can deposit your paycheck -- or not even that, just to give you a signature authorizing their bank to transfer money to you, where "you" means the person who can prove they hold the private key corresponding to a public key you gave your employer.

Banks shouldn't even need to know your name if things were being done securely, much less your SSN. Having them is nothing but a liability because someone who doesn't know what they're doing could mistake them for an authentication method.


You do need the SSN to match up with the name and other personal information like age, gender, address, etc. In that way, it's a bit like authenticating with a common username and a password that is publicly available with the username obfuscated (except in the case of data leaks).


Instead of a unique ID like a SSN, we should be using an identity provider to support such use cases. Imagine instead that you would authenticate with https://login.gov (ideally with your credentials and a hardware 2FA device), which would then attest to whatever service you were logging in to that you are you.

You can't rotate a social security number with reasonable effort, and we can longer treat it as a secret, because it isn't one. It's time to move past it as an identifier.


Now imagine that for whatever reason you suddenly become persona non grata, and https://login.gov/ refuses to attest that you are you to any of the services you have come to depend on.

Or just imagine https://login.gov/ passively collecting information about all the services you're logging into.

I wouldn't be opposed to common login protocol—preferably a distributed or federated one—where the government and other parties can add their own signatures to attest that a particular identity belongs to a certain real-world person, and you can choose which of those signatures you present to any given service. However, having the login itself go through a government server would be an incredibly bad idea.


We're already at that point (driver's licenses, passports) and it hasn't happened yet. Yes, you can get blacklisted by the TSA for air transport, but they have an exception process for that (redress control number).

Proper functioning of democracy and government requires eternal vigilance (apologies to Jefferson).


You don't need your driver's license or passport to log in to your e-mail or Facebook account and communicate with your friends, or to buy groceries. Revoking your driver's license and passport affects your ability to travel long distances and not much else, at least in the short term. It's bad enough that you need a current government ID for domestic flights; we don't need to make it mandatory for everything.

> Proper functioning of democracy and government requires eternal vigilance

Indeed, and part of that vigilance is pushing back against government involvement in areas they have no business in, such as authentication for non-government services.


Nobody is proposing a system where you need to authenticate with some national ID in order to do any of the things you mentioned.

We are talking about having better authentication (both more privacy-aware and more flexible) for situations where it's needed. You don't need to validate your identity for email, facebook, or groceries, so obviously this wouldn't apply there. This would apply to things where some ID auth is already taking place (e.g. anything that asks for your SSN, KYC processes in general, etc).


It was, of course, never intended to be used as an authenticator, nor a secret in any way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: