Web3 Authentication 101
A primer of all the authentication and validation standards your dapp needs to support
Hello 0xPass fam -
If you're a web3 developer looking to create rich, contextual user experiences with support for account abstraction, you'll need to be familiar with the following authentication and signature validation standards:
ERC-4361: Sign In With Ethereum
ERC-1271: Standard Signature Validation Method for Contracts
ERC-6492: Signature Validation for Predeploy Contracts
In this post, we'll delve into each of these standards.
If you find this content helpful, please consider sharing it with others and checking out our product, 0xPass.
We're also hiring a Founding Engineer [JD here] and possibly a Head of Growth too! Please let me know if you or someone you know would be interested :)
Wallet Connection vs Authentication
Connecting your wallet to a dapp lets it identify which account you're using without retaining any information about your identity. This used to be sufficient since dapps required users to sign every on-chain transaction.
However, with the evolution of dapps, there's a need to store user preferences and information to provide more contextual user experiences, which requires wallet authentication.
ERC-4361 → Sign In With Ethereum
Sign-In with Ethereum offers a solution for dapps to authenticate and create user sessions for wallets in a self-custodial manner.
By adopting this standard, dapps can improve the user experience while ensuring that the user remains in full control of their data.
The flow is simple: the user connects their wallet, then they're prompted to sign a message that proves they truly own the wallet they're claiming to hold, which in turn creates a user session.
However, there's a catch - SIWE works with EOAs but not with smart wallets which account abstraction relies on. This is where ERC-1271 comes into the picture.
ERC-1271 → Standard Signature Validation Method for Contracts
We went over this standard in an earlier post as well, which you can find here.
Smart wallets can have arbitrary signature validation logic. Thus, ERC-1271 requires the verifier or the dapp to call a function called isSignatureValid on the smart wallet for validation purposes.
Quoting ERC-1271 -
isValidSignaturecan call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependent (e.g. signers authorization level within smart wallet), signature scheme Dependent (e.g. ECDSA, multisig, BLS), etc.This function should be implemented by contracts which desire to sign messages (e.g. smart contract wallets, DAOs, multisignature wallets, etc.) Applications wanting to support contract signatures should call this method if the signer is a contract.
Awesome - problem solved! Or is it?
Smart wallets are counterfactual contracts, which means that contract deployment is deferred until the first user transaction for UX purposes.
So how will dapps authenticate users with an undeployed smart contract wallet? They can't access the isValidSignature function! This is where the latest proposal, ERC-6492 comes into play.
ERC-6492 → Signature Validation for Predeploy Contracts
At its core, ERC-6492 proposes a contract called the UniversalSigValidator, which validates smart wallet signatures.
There are two possibilities here -
Signature ends with a sequence of magic bytes
If a signature ends with a sequence of magic bytes we know that the smart wallet is undeployed.
At this point, the verifier, or the dapp in this case, can later simulate a deployment of the smart wallet and then validate the signature.
Magic bytes are undetected in signature
Proceed with ERC-1271
However, this ERC is still in review and in the process of being peer-reviewed.
Should dapps implement these standards?
Yes, they should. To bring all the account abstraction benefits to life, dapps need to implement all these standards. However, as a dapp developer, you can use open source libraries like Ambire’s Signature Validator.
How 0xPass handles these standards
Think of 0xPass as a wallet connector like RainbowKit but with built-in support for authentication, identity management, and account abstraction.
This allows us to hide all of the signature validation work from developers using our product, so they don't have to worry about implementing all these standards themselves! This is especially important as these standards evolve - as might be the case with ERC-6492.
Thank you for reading!
Feedback
If you’ve read this whole post, please give me some feedback! What do you like about these posts? How can we improve? Any other topics you want us to dive into?
References
Ethereum Improvement Proposal 6492. Retrieved from https://eips.ethereum.org/EIPS/eip-6492
Ethereum Improvement Proposal 1271. Retrieved from https://eips.ethereum.org/EIPS/eip-1271
Ethereum Improvement Proposal 6492. Retrieved from https://eips.ethereum.org/EIPS/eip-6492
ERC-6492 and Why it's Important for AA. Zero Dev. Retrieved from https://docs.zerodev.app/blog/erc-6492-and-why-its-important-for-aa
AmbireTech. Signature Validator. GitHub. Retrieved from https://github.com/AmbireTech/signature-validator
Sign in with Ethereum is a Game Changer (Part 1). Spruce. Retrieved from https://blog.spruceid.com/sign-in-with-ethereum-is-a-game-changer-part-1/
