-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specialization to Email-based Account Recovery #47
Comments
In the above spec, the wallet provider will need to implement the following things:
|
Is this done with ether-email-auth? @SoraSuegami |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue proposes to build new contracts, circuits, and a relayer implementation specialized to email-based account recovery by removing/modifying the current Email Wallet codes.
After launching Email Wallet, we found a huge demand to use email-triggered transactions to recover existing AA wallets.
Although extensions can already cover such use cases, the generic nature of Email Wallet forces guardians to do additional processes that are not intuitive, e.g., sending an email to install the account recovery extension.
Besides, if the wallet provider operates the current relayer as it is, the guardians can also request the wallet provider to process transactions that are not related to account recovery, imposing unnecessary costs and regulation risks on the provider.
For these reasons, I think we should make new protocols and codes specialized to email-based account recovery.
Instead of building the email-based account recovery from zero, we can do that by removing and modifying the specs of Email Wallet. This approach not only reduces the implementation costs but also allows the specialized protocol to keep the same security model. Specifically, we modify the current specs as follows:
{string}
,{uint}
,{int}
,{amount}
, and{address}
. The email address in the subject is not supported because unclaimed funds and states are disabled. Note that{amount}
can be renamed to{decimal}
.Guard {address}
. It sets{address}
to the guarding wallet address for the guardian's Ethereum address, i.e.,guardingWallet[guardianAddr] = walletAddr
. Note that we assume the guardian uses different account keys (=guardianAddr
) for eachwalletAddr
even when the same email address and the relayer are used.dkimRegistry
variable is used to specify the DKIM registry contract for its guardian.string[][] subjectTemplates
address dkimRegistry
recover(uint8 templateIndex, bytes[] memory subjectParams, address guardianAddr, bytes32 emailNullifier)
Guard
, the Email Wallet core contract calls therecover
function defined in the wallet contract ofguardingWallet[guardianAddr]
. Therefore, each wallet can customize subject patterns and parameters by defining its ownsubjectTemplates
andrecover
.The text was updated successfully, but these errors were encountered: