undefined | Better HN

0 pointsmhink3y ago0 comments

> Basically, the core problem is digital identities (accounts, IPs, phone #s etc.) are cheap to create (even considering captchas and all) so fraud is easy. The solution could be just to make it "costly" to create new digital identities. For example, you could get a "verified but anonymous" identity issued by locking some assets (could be real world money, or maybe something intangible like community reputation) as collateral with a trusted party (or, for the crypto people, the blockchain). If you misbehave, you lose your reputation on that identity (and essentially your collateral) and have to start over. This lets anyone bootstrap a "minimal" level of trust at the beginning before they can use time to prove themselves trustworthy.

I've always thought that client certs would be an interesting solution to this problem. Any given certificate can carry signatures from multiple signing authorities, right? So we could imagine a world where there are many different certificate authorities, each of whom have their own criteria for signing a particular certificate and each of whom offer different varieties of assurance regarding the signature-holder's identity.

From here, the question of "should I allow the user identified by this client cert to use my service" simply becomes a question of 1.) checking the validity of the signatures of the client cert and 2.) deciding if the CA's criteria for signing certs aligns with my desired userbase.

For example, a particular CA might insist that their users go through some real-world process to renew their certification every few years, but when they sign a cert it means that the bearer has been strongly vetted as a real person.

An interesting side effect of this auth model is that a service provider accepting certs from a particular CA has someone to complain to if a user bearing their signature acts improperly on their platform. You could imagine a CA which has a code of conduct expected of the users whose certs they sign, and would perhaps revoke a user's certification if too many websites complain.

0 comments

2 comments · 1 top-level

unwise-exe3y ago· 1 in thread

That's not safe for a lot of sites, though.

I hear that porn tends to be officially frowned on in a fair number of places.

Reading non-approved news is dangerous in some places.

Honestly debating political topics can be super dangerous if you're identifiable.

Sometimes even having a login on a site is dangerous, I think I heard about this after a non-mainstream discussion site got hacked like a hear and a half ago.

mhinkOP3y ago

So, my thought process here was: given a fairly robust selection of certificate authorities, a given user could have a number of different client certs for use in different trust scenarios. Contrast the following:

- A user bearing a client cert with the name "Jonathan Grant", signed by a U.S. government agency which is known to verify that its signees' certs are a citizen of the United States.

- A user bearing a client cert with the name "Michael Black", signed by Alice, who is known to only sign certs after verifying that the real-world identity of the signee matches the name on the cert.

- A user bearing a client cert with the pseudonym "c00ln4m3", signed by Bob, who is known to only sign a single cert for any given real-world person. (To do so, he verifies the person's real-world identity but does not reveal which cert corresponds to which person.)

- A user bearing a client cert with the pseudonym "hunter217", signed by Charlie, who is known to sign certs without verifying the real-world identity of his signees at all, but who is also known to revoke his signature on certificates if a service provider complains about the user bearing that cert.

- A user bearing a client cert with the pseudonym "cypr3ss", signed by David, who is known to charge $1000/year for a cert bearing his signature but performs no other identity verification.

The point of listing out these different scenarios is that the underlying mechanism (client certs) is the same, but the end-user and the service provider don't actually have to trust each other: they only have to agree on a CA with mutually acceptable policies.

j / k navigate · click thread line to collapse