Introduce a universal account abstraction recovery mechanism recoverAccess(subject, provider, proof) along with recovery provider management functions for smart accounts to securely update their access subject.
Account abstraction and the "contractization" of EOAs are important Ethereum milestones for improving on-chain UX and off-chain security. A wide range of smart accounts emerge daily, aiming to simplify the steep onboarding curve for new users. The ultimate smart account experience is to never ask them to deal with private keys, yet still allow for full account control and access recovery. With the developments in the Zero-Knowledge Artificial Intelligence (ZKAI) and Zero-Knowledge Two Factor Authentication (ZK2FA) fields, settling on a common mechanism may even open the doors for "account recovery provider marketplaces" to emerge.
The account recovery approach described in this proposal allows for multiple recovery providers to coexist and provide a wide variety of unique recovery services. In simple terms, smart accounts become "recovery provider aggregators", making it possible for the users to never rely on centralized services or projects.
The Account Abstraction Recovery Interface (AARI) aims to define a flexible interface for any smart account to implement, allowing users to actively manage their account recovery providers and restore the access of an account in case of a private key loss.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
A smart account willing to support AARI MUST implement the following interface:
A recovery provider MUST implement the following interface:
The AARI is expected to work with any account abstraction standard to allow for maximum account recovery flexibility. Whether it is EIP-4337 or EIP-7702, a particular smart account provider may support account recovery by simply implementing a common interface.
Since the whole account recovery process is nothing but proving the knowledge of some alternative secret to a private key, it is essential for accounts to be able to "commit" to this secret. The subscribe function in the recovery provider interface allows precisely for that. Moreover, if at some point in time a user wanted to "recommit" to a new secret (due to security reasons), they could multicall unsubscribe + subscribe functions to achieve the desired result.
The recovery functions accept arbitrary bytes as subject and object parameters to allow for a variety of access control rules to be recovered, since many smart accounts are ownerless and have no "owner" address to be directly substituted.
This EIP is fully backwards compatible.
There are several security concerns to point out:
addRecoveryProvider and removeRecoveryProvider functions.Copyright and related rights waived via CC0.