3 ms·

So what _should_ we replace SSNs with? Obviously some kind of system based on asymmetric cryptography would be ideal, but what system, specifically? There are

So what _should_ we replace SSNs with? Obviously some kind of system based on asymmetric cryptography would be ideal, but what system, specifically? There are a lot of competing concerns here, not the least among them being privacy. For example, if a system based on public key cryptography becomes commonplace in the US, will websites start using that same system for authentication? There are some rather significant privacy issues associated with having a government issued, globally unique ID associated with your account on random websites. Maybe this is something the tech industry in the US should be involved in? I imagine lots of companies would jump at the chance to be involved in a standards group designing a unified method for citizen authentication in the US.

vpeters25 9y ago
Maybe we don't need a unique id at the federal level after all. Financial institutions are already required to follow KYC (Know Your Customer) laws. For this they need a way to validate the identity of the customers they do business with. I guess they already have enough ways to do this without relying on SSN or a potential national id card. BTW, after the Equifax hack, financial institutions should be mandated to stop trusting SSN as proof of identity.
- dredmorbius 9y ago
  I'm thinking of the number of government-level identifiers which might be needed / used: * Tax authority (TIN). * Pensions system (e.g., SSN) * Possibly a voting ID, though that's fraught. * Military or national service ID. * State tax ID. * Drivers registration. * Real estate / property ID. * Medical records ID. * Social benefits ID. * Other registrations, e.g., weapons, broadcast licenses, etc.
pandemi 9y ago
In the Nordic countries we have 2 factor authentication with your bank used as means of authentication. See for example BankId in Sweden. Tools like this reduce the use of SSN to a username instead of a password like it should be.
dredmorbius 9y ago
This is a major concern of mine as well. For some purposes, there's a need for a single identifier. For others, various counterparties only need to agree that they are talking about the same party. Creating paired (or multi-part) keys might work for that. (This could also cut down on the rampant and promiscuous data exchanges that occur currently, particularly if the subject of the data had to participate in the making of any such shared identifier.) For the general case of online identity, I'd really like to see the concept of an identity manager, with various policies which could be set, both as defaults and with specific counterparties. As an example, I might have a policy that "all sites default to a one-time session identifier which is destroyed after 24 hours". This gives a stateful history for 24 hours, but a clean slate afterwards. It should be enough for basic site navigation, but not for deeper interactions (e.g., posting inane comments to HN). The periods might be longer or shorter. For a select set of sites, persistent IDs might be presented, but specific only to a given site. And where necessary, a set of sites might have a common ID. Say, a cluster of systems used for work purposes. And if needs be, you might have a limited set of systems -- your government pensions account, tax systems, and voting registration, say -- which link to a specific government-issued ID. For such a system, I see a physical token (I'm partial to very-near-field chips in a worn form-factor, say an NFC-ring), some additional input (password, passphrase, possibly biometrics), and then, by way of an identity management system (probably on a local device), the identity assertion specific to a given service is offered. There are any number of other elments to this, including the problems of deanonymising data and such. For that I see legal reforms coming into place, which is a longer discussion.

vpeters25 9y ago

Maybe we don't need a unique id at the federal level after all. Financial institutions are already required to follow KYC (Know Your Customer) laws. For this they need a way to validate the identity of the customers they do business with. I guess they already have enough ways to do this without relying on SSN or a potential national id card. BTW, after the Equifax hack, financial institutions should be mandated to stop trusting SSN as proof of identity.

dredmorbius 9y ago
I'm thinking of the number of government-level identifiers which might be needed / used: * Tax authority (TIN). * Pensions system (e.g., SSN) * Possibly a voting ID, though that's fraught. * Military or national service ID. * State tax ID. * Drivers registration. * Real estate / property ID. * Medical records ID. * Social benefits ID. * Other registrations, e.g., weapons, broadcast licenses, etc.

pandemi 9y ago

In the Nordic countries we have 2 factor authentication with your bank used as means of authentication. See for example BankId in Sweden. Tools like this reduce the use of SSN to a username instead of a password like it should be.

dredmorbius 9y ago

This is a major concern of mine as well. For some purposes, there's a need for a single identifier. For others, various counterparties only need to agree that they are talking about the same party. Creating paired (or multi-part) keys might work for that. (This could also cut down on the rampant and promiscuous data exchanges that occur currently, particularly if the subject of the data had to participate in the making of any such shared identifier.) For the general case of online identity, I'd really like to see the concept of an identity manager, with various policies which could be set, both as defaults and with specific counterparties. As an example, I might have a policy that "all sites default to a one-time session identifier which is destroyed after 24 hours". This gives a stateful history for 24 hours, but a clean slate afterwards. It should be enough for basic site navigation, but not for deeper interactions (e.g., posting inane comments to HN). The periods might be longer or shorter. For a select set of sites, persistent IDs might be presented, but specific only to a given site. And where necessary, a set of sites might have a common ID. Say, a cluster of systems used for work purposes. And if needs be, you might have a limited set of systems -- your government pensions account, tax systems, and voting registration, say -- which link to a specific government-issued ID. For such a system, I see a physical token (I'm partial to very-near-field chips in a worn form-factor, say an NFC-ring), some additional input (password, passphrase, possibly biometrics), and then, by way of an identity management system (probably on a local device), the identity assertion specific to a given service is offered. There are any number of other elments to this, including the problems of deanonymising data and such. For that I see legal reforms coming into place, which is a longer discussion.