Update: I have been working on a better flow for verifications, that will make the KBFS proof itself two way binding (by signing a proof with the Ethereum address private key).
Update 2: New article has been published now:
How Aragon approaches identity and the Ethereum Keybase Resolver_Identity is one of the most important parts when developing decentralized applications. This is specially true for…_medium.com
When it comes to building decentralized apps, identity verification is important not only for performing KYC but also for easily searching addresses with human readable and memorable strings. While ENS might solve the later, it is also very important to be able to have further off-chain proofs of who that person is.
Keybase is a service that allows for identity linking and verification using cryptographic proofs. Keybase recently introduced KBFS a cryptographically secure cloud storage. This allows users to have a public folder with files, and have a cryptographic proof that only the user that owns the directory is allowed to put those files there. Therefore we can prove that an arbitrary piece of data was put there by a certain user.
Even though you can link a Zcash and Bitcoin address to your Keybase identity, at the moment there is no way to be certain that a user really controls the addresses listed, as no verification is required from the cryptocurrency part.
When building Ethereum addresses verification for Keybase it is very important to provide two-way verification, so applications can be certain that the address linked with your username is really yours.
Using KBFS, a user can add a file to their public specifying the Ethereum address they want to verify. This is already a valid one-way proof, we know that only the user that owns the Keybase account, is specified a certain address. This is similar to what Keybase provides for BTC and Zcash right now.
Then, the user performing the verification has to execute a function in the registry smart contract specifying their Keybase username from the address they are trying to verify. The contract will then perform an HTTP request to Keybase (using Oraclize) to fetch that user’s Ethereum address.
If it matches, then the registry will create an entry for that user and address. The registry allows for two-way searching, that is username to address and address to username.
Saving the eth file to KBFS
Watching the Keybase Registry contract
Executing the claim function
You can find the source code for the initial implementation of the registry here and see the currently deployed contract on Etherscan.