STEEM PROPOSAL: Implementing Third Party Certificate Authorities To Combat Sybil

Sock Puppets = Bad
More Sybil Resistance = Good

What is more important... convenience and privacy, or more fairness in content curation? People hand over their identities to legacy social networks without any qualms. I suggest it is more important that the content curation and reward system is more fair. This is my proposal to make Steem more fair by making it more resistant to Sybil.

Foreword:
I first came up with this idea for decentralized poker networks in order to combat a form of cheating in poker called "multiaccounting". Multiaccounting is a form of a Sybil attack in poker where someone(s) registers multiple users, and then plays in the same games with their own multiple users, with the intent to increase their chances of winning or manipulate gameplay to increase their chances of winning. I think that my idea can be useful for Steem as well. I see Sybil manipulation as being the main issue with decentralized social networking in which participants are paid for their participation. Admittedly, this idea needs some love/tweaking/feedback and is not a finished proposal.

How It Works (TL;DR Version):
In a nutshell, I am suggesting Steem utilize third party certificate authorities to make it harder for one person to create multiple Steem identities with the intent to game the reward system. Here is how it would work:

1. Third party CAs (Certificate Authorities) would have the ability to verify Steem users’ identities by manually verifying a Steem user's government-issued photo IDs.
2. CAs would then issue a "Certificate of Identity", which will then be associated to the Steem user's account and recorded permanently on the blockchain. The user's identity will stay anonymous to everyone but the CA.
3. The Certificate of Identity is made from what I have termed the "Identity Hash". The CA will create an “Identity Hash” by putting the user’s identity data obtained from their government-issued ID into a one-way hash function in a predetermined format. For instance, the predetermined format would be something like: firstName, lastName, birthDate, sex, city, state, country, documentNumber.
4. The resulting "Identity Hash" hash will be different for each user. Users will remain anonymous to everyone but the CA, but other users benefit by knowing that the verified user is a genuine person and that he has not created multiple Steem users.
5. Steem users then need to be able to vote on which Certificate Authorities they trust, similar to how they can vote for what Delegates they prefer. The certificates issued from the CAs with the most votes would be weighted as being more important than certificates issued from CAs with less votes.
6. Steem users that have verified their identity with the CAs who have the most votes should be given more weight in Steem Power calculations, as they are less likely to have registered more than one user to game the content curation (or rewards) system.
7. No one would have to verify their identity if they did not want to, and they could still receive SP/SD if they do not. However, I am suggesting that those that do receive a bonus in the curation calculations, as we can be relatively sure that they are not a sock puppet.

Random Details In No Specific Order:

• Third parties would perform this service for the community, as a human is needed to verify the validity of the ID and retrieve the information needed to generate the certificate of identity. There is no way to do this autonomously, so you, I or anyone else could become a Certificate Authority if we so wished.
• Ideally, Certificate Authorities should be trusted members of the community. This I think will happen naturally, because who would want to share their identity with someone that may abuse it?
• Ideally, there would be multiple certificate authorities to reduce the likelihood that one certificate authority is corrupt. Someone that has registered their identity with multiple authorities should be given more validity than someone that has only registered with one.
• In order for people to perform this service, Certificate Authorities need to be allowed to make a profit, which also provides incentive for them to be honest.
• The Ceritificate Authorities should be able to set their own price for issuing certificates. Since there will be multiple certificate authorities which compete, the price to quality to trustworthiness of certificates will eventually reach an equilibrium. Competing Certificate Authorities will result in the cheapest cost possible for users.
• Certificates should be revocable in case someone’s private key is compromised, and they need to switch accounts.
• Certificates should expire every year, so that the integrity of the certificate is maintained. To do this a "stale date" should be publicized at the time a certificate is issued. The stale date is the date the certificate will be voided on.
• Steem should have strict regulations in place, as to the security of the data certificate authorities and standards, so that the certificates’ integrity and identity documents are secure, certificates are compatible across multiple certificate authorities, and no one can create multiple identities.
• Create industry security standards for securing player documents sent to certificate authorities. All documents should be destroyed after a certificate is issued to avoid massive identity theft.
• Certificate Authority Best Practices
  o All CA accounts should utilize multi-signature or account permissions to protect the integrity and validity of the certificates.
  o All CAs should make their identities public and prove they own the account they are issuing the certificates from.
  o All CAs should sign a contract stating that they will not misuse identifying documents and the identities of account holders, and follow the standards outlined by the community. A hash of the contract should be stored on the blockchain, and could be submitted as evidence in a court case against the Certificate Authority in the case of any types of fraud committed by them.
  o Files sent to each CA should be encrypted to a public key published on the blockchain, so only the CA can view the files.
  o To avoid interception of the identity files, any files received by the CA should only be unencrypted on an offline computer for privacy reasons.
  o After receiving identifying documents, a one-way hash function should be used by the CA to create an identity signature according to the certificate standards set by the community. This is done by sending an “Identity String” through a one-way hash function.
  o All CAs must use the same one-way hash function, so someone submitting the same identity document to multiple CAs will result in the same Identity Hash.
  o Standard “Identity String” Example: “Full name, Date of Birth, Sex, Eye Color, Physical Address, Country, Driver’s License (or Document) Number”
  o Why more than a name and birth date? A lot of people have the same names, including generational same names (Jr., III, IV, etc), and google “The Birthday Problem”. The more information included in the “Identity String” will make it exponentially less likely someone would be able to brute force the “Identity Hashes”.
  o After creating an identity signature, the unencrypted and encrypted files used to generate the identity signature should be permanently destroyed via secure file shredding methods.

A Means to an End:
Utilizing CAs in this way is a means to an end and is not meant to be a permanent solution, but instead it is meant to be a short term solution. Eventually, when the technology is feasible, it is ideal to phase out certificate authorities with the use of biometrics and cryptographic fingerprints. At the moment, the technology regarding anonymous, decentralized and digital biometric identities is not where it needs to be.

Additional Sybil Resistant Methods That Should Be Considered:
Additional ideas that should be considered to combat Sybil include computationally extensive identities, reputation systems, and web of trust systems. However, those should probably be split into their own separate proposals/threads, and so I will leave those for another discussion.