Social Login

While the challenges in the adoption of Web3 technology are myriad in nature, perhaps the more interesting areas of concern revolve around the handling of Confidentiality, Integrity, and Availability of data.

Though the application of this information security model is unique to each individual and use case, the more common consensus is that this process, more often than not, is rather complicated, especially so in the Web3 space.

The Problem: Web3's Complicated Login

The nature of login processes within Web3 comprises a few different mechanisms, usually delving into either of the following two methods:

• Cryptographic key pairs - Private key information

• Mnemonics ranging from 12 - 24 words

The necessity to commit to memory or secure complex strings of data for signing into crypto wallets poses unnecessary complexity to individuals exposed to and comfortable with a Web2 experience.

Furthermore, given the inherent nature of irrecoverability of private key and/or mnemonic data when lost, results in an uncomfortable user experience, which poses a barrier for entry into the Web3 space for most individuals.

The Solution: Social Login

Logic would dictate that the simplest and most efficient solution would be to adopt existing solutions to problems rather than inventing new ones.

By adopting a mechanism in which existing Web2 sign-in flows could be utilized for Web3, aside from resolving the user experience crisis faced on Web3, would yield a consequential benefit of improving user acquisition, due to the conversion rate of existing Web2 accounts with this approach.

The challenge, however, would be to verify the validity of a user's ownership of an account without the storage of sensitive personal data on the blockchain, even more so with data being publicly available on the blockchain.

Enter the concept of Social Login!

Social login is a zero-knowledge proofs (ZKPs) approach to prove that a statement is true without revealing any unnecessary information aside from that which is required to validate the truthfulness of the statement in question. Therefore, by leveraging ZKPs, it is possible to keep sensitive personal data private, whilst proving that a user owns said sensitive data. The most suited of these ZKPs, in specificity to blockchain networks, is Zero-Knowledge Succinct Non-Interactive Argument of Knowledge, also known as zk-SNARK.

Utilizing zk-SNARKs, one can prove ownership of information without revealing the information itself, and without interaction between the prover and the verifier. A common example of this would be through the employ of a valid JSON Web Token (JWT).

A rather simplified example of one such flow of a ZKP-enabled transaction can thus be:

• A signing key (i.e. private-public key pair) is generated, which will be registered in the on-chain account belonging to the user tied to the social account.

• The user does a Google OAuth2 login, and the JSON Web Token (JWT) is returned.

• The address will be derived from the user's JWT.

• The JWT is sent to the proving service, and the generated proof is returned.

• The proof and public information (e.g. address) are sent on-chain to register the key.

• The verification is performed on-chain, and if the proof is valid, the signing key will be registered under the user account.

• Subsequently, the user's wallet client uses the signing key to authorize transactions for their account.

Figure 6.0. Social Login Flow

Social Login's Role in AELF

A zk-SNARK proving service can replace the need for centralised services that verify users' credentials, reducing the probability of failure and increasing the security of the overall system.

The verification is moved to the on-chain instead, through the use of the zk-SNARK proof generated by the proving service.

As computing speed improves, it may be possible to generate zk-SNARK proofs locally in the near future, eliminating the need for zk-SNARK as a proving service. Meaning, the JSON Web Token (JWT) used to generate the zk-SNARK proof doesn't exit the user's device, further improving the security of the login mechanism, given the lack of need to trust an external prover service.