User identity in DApps
One of the major advantages of DApps is that it generally guarantees user anonymity. But many applications require the process of verifying user identity to use the app. As there is no central authority in a DApp, it become a challenge to verify the user identity.
In centralized applications, humans verify user identity by requesting the user to submit certain scanned documents, OTP verification, and so on. This process is called know your customer (KYC). But as there is no human to verify user identity in DApps, the DApp has to verify the user identity itself. Obviously DApps cannot understand and verify scanned documents, nor can they send SMSes; therefore, we need to feed them with digital identities that they can understand and verify. The major problem is that hardly any DApps have digital identities and only a few people know how to get a digital identity.
There are various forms of digital identities. Currently, the most recommended and popular form is a digital certificate. A digital certificate (also called a public key certificate or identity certificate) is an electronic document used to prove ownership of a public key. Basically, a user owns a private key, public key, and digital certificate. The private key is secret and the user shouldn't share it with anyone. The public key can be shared with anyone. The digital certificate holds the public key and information about who owns the public key. Obviously, it's not difficult to produce this kind of certificate; therefore, a digital certificate is always issued by an authorized entity that you can trust. The digital certificate has an encrypted field that's encrypted by the private key of the certificate authority. To verify the authenticity of the certificate, we just need to decrypt the field using the public key of the certificate authority, and if it decrypts successfully, then we know that the certificate is valid.
Even if users successfully get digital identities and they are verified by the DApp, there is a still a major issue; that is, there are various digital certificate issuing authorities, and to verify a digital certificate, we need the public key of the issuing authority. It is really difficult to include the public keys of all the authorities and update/add new ones. Due to this issue, the procedure of digital identity verification is usually included on the client side so that it can be easily updated. Just moving this verification procedure to the client side doesn't completely solve this issue because there are lots of authorities issuing digital certificates and keeping track of all of them, and adding them to the client side, is cumbersome.
Why do users not verify each other's identity?
Often, while we do trading in real life, we usually verify the identity of the other person ourselves or we bring in an authority to verify the identity. This idea can be applied to DApps as well. Users can verify each other's identity manually before performing trade with each other. This idea works for specific kinds of DApps, that is, for DApps in which people trade with each other. For example, if a DApp is a decentralized social network, then obviously a profile cannot be verified by this means. But if the DApp is for people to buy/sell something, then before making a payment, the buyer and seller can both verify each other's identity. Although this idea may seem fine while doing trading, when you think practically, it becomes very difficult because you may not want to do identity verification every time you trade and everyone not knows how to do identity verification. For example, if the DApp is a cab-booking app, then you will obviously not want to perform identity verification before booking a cab every time. But if you trade sometimes and you know how to verify identity, then it's fine to follow this procedure.
Due to these issues, the only option we are currently left with is verifying user identity manually by an authorized person of the company that provides the client. For example, to create a Bitcoin account, we don't need an identification, but while withdrawing Bitcoin to flat currency, the exchanges ask for proof of identification. Clients can omit the unverified users and not let them use the client. And they can keep the client open for users whose identity has been verified by them. This solution also ends up with minor issues; that is, if you switch the client, you will not find the same set of users to interact with because different clients have different sets of verified users. Due to this, all users may decide to use a particular client only, thus creating a monopoly among clients. But this isn't a major issue because if the client fails to properly verify users, then users can easily move to another client without losing their critical data, as they are stored as decentralized.
The idea of verifying user identity in applications is to make it difficult for users to escape after performing some sort of fraudulent activity, preventing users with a fraud/criminal background from using the application, and providing the means for other users in the network to believe a user to be whom the user is claiming to be. It doesn't matter what procedure is used to verify user identity; they are always ways for users to represent themselves to be someone else. It doesn't matter whether we use digital identities or scanned documents for verification because both can be stolen and reused. What's important is just to make it difficult for users to represent themselves to be someone else and also collect enough data to track a user and prove that the user has done a fraudulent activity.