TLDR— We represent a new signer for account abstraction wallets or SDK for having passkey based login mechanism. The passkey allows users to use their device authentications like face id, touch id or passwords to create a wallet and make a transaction.
Thanks to @nlokande for reviews and discussions
According to the ethers documentation, a signer is:
"…an abstraction of an Ethereum Account, which can be used to sign messages and transactions and send signed transactions to the Ethereum Network to execute state-changing operations."
The PasskeySigner package will extend the abstract signer provided by ethers and offer the functionality to sign transactions, messages, and typed messages for blockchains using passkeys. A passkey is a digital credential tied to a user account and a website or application. Passkeys allow users to authenticate without entering a username or password or providing any additional authentication factor. This technology aims to replace legacy authentication mechanisms such as passwords. Passkeys serve as a replacement for private key management, offering faster sign-ins, ease of use, and improved security.
Bundlers and EntryPoint in this context refer to the same concepts mentioned in ERC 4337.
There are several advantages:
Gas cost: On-chain signature verification for passkey-based transactions incurs significant gas costs. Efforts have been made to reduce the gas cost for verification. Opclave utilizes a custom rollup with the "secp256r1 verifier" precompile contract following Optimism's Bedrock Release standards. Ledger is also working on further optimizing gas costs.
Device dependency: Though passkeys are device dependant there are workarounds. Apple device users can securely back up their passkeys in iCloud Keychain, overcoming this restriction. For other devices, the module will provide multi-device support, allowing users to add multiple owners (devices) to their smart contract wallet.
The initialization would be straight forward if the wallet sdk has itself has exposed necessary interfaces for accepting an external signers. For example let’s suppose if there’s a wallet sdk known as abc sdk. And let’s assume it accepts the signer while initializing it’s instance so in that case the integration would look like this
Flow of making a transaction will look like this
One of the notable features of smart contract wallets is the provision of custom signatures for transactions. Among the prominent signature schemes, secp256R1-based signatures stand out. It's important to note that secp256k1 is a Koblitz curve, whereas secp256r1 is not. Koblitz curves are generally considered slightly weaker than other curves. Both secp256k1 and secp256r1 are elliptic curves defined over a field , where p represents a 256-bit prime (although each curve uses a different prime). Both curves adhere to the form . In the case of the Koblitz curve, we have:
For R1 we have:
The R1 curve is post-quantum resistant and supports major hardware enclaves. However, most security enclaves cannot generate K1-based signatures, which are commonly used by EVM blockchains for signing transactions and messages.
A typical ethers signer signs transactions by either having the private key itself or by being connected to a JsonRpcProvider to fetch the signer. However, the Passkey Signer operates differently as it does not possess the private key. Instead, it can sign transactions and messages by sending them to the hardware, and the signed string is provided as the output.
The public-key is extracted and that is passed to the smart contract wallet.
During authentication an assertion is created, which is proof that the user has possession of the private key.
The publicKeyCredentialCreationOptions object contains a number of required and optional fields that a server specifies to create a new credential for a user.
This Signer will be only compatible for smart contract wallets and cannot sign messages and transactions for an EOA.
The interaction with the hardware will be done using the webauthn library which allows us to generate new cryptographic keys within the hardware. The public key which is an (x,y) co-ordinate, corresponding to this private key is fetched. These co-ordinates should be stored inside the smart contract wallets and they will act like a owner to the smart contract wallet.