Community activity in Flow forums, FLIPs and PRs in recent months has progressed an impressive number of new Cadence language features relating to accounts, account access and security concerns, and/or capabilities and their management. The creation of these features is, in part, to support the broader vision for walletless-onboarding and Hybrid Custody on Flow. Once implemented, we believe Flow can provide the best-in-class UX for friction-less engagement with dapps without upfront wallet setup or funding requirements, coupled with the smooth transition to a self-custody account later.
In parallel the Flow team have been iterating on a proof-of-concept implementation of Account Linking and Delegation to help understand design options, and to surface risks and limitations. However, Account Linking and Delegation as it is realized in the PoC today does not integrate any of the new proposed language features - and yes, some have yet to be finalized themselves. Given the complexities of these features, the security sensitive domain being handled, and the value of Account Linking and Delegation functionality to the broader ecosystem, it seems worthwhile and necessary to consider a Cadence contract standard. The standard would ensure interoperability for how dapps integrate the onboarding experience, reduce complexity for builders, and establish a robust and secure model for working with accounts.
Going forward, we want to involve the community to align on the role of the standard, help with agreeing the specification, and settle remaining open questions so it can be implemented. To that end we will propose a FLIP PR in the coming days, through which the items detailed below will need to be resolved. We will also be setting up specific community breakouts for this topic once the current round of breakouts has wrapped up.
Account Linking FLIP contents
The proposed standard sets down primitives through which well-known web2 account-to-application authorization schemes can be modeled in our decentralized context.
Here’s what the FLIP will not propose:
- Create a standard for shared access on a user’s primary account
- Introduce guardrails for the use of AuthAccount Capabilities
For the purposes of the FLIP, we will focus on how to manage the AuthAccount Capabilities delegated to an account, not necessarily on the discussion of whether that delegation should occur or the mechanism for delegation. While those topics are of course important, relevant, and will have implications for the details of what is managed by the constructs discussed here, the AuthAccount Capability FLIP (implemented here) is allocated for such discussions.
We hope to cover the following in settling the design and best practices for the standard:
- Child account creation
- Child AuthAccount capability management
- Viewing existing child accounts
- Adding an account as a child account
- Revoking hybrid custody approval/access granted to a child account
- Identifying an account’s child accounts
- Identifying an account’s parent account(s)
- Delegating Capabilities to a child account from the parent’s ChildAccountManager
- Easily viewing the assets in an user’s child accounts
Integration of new language features
A critical outcome we are looking for from the proposed FLIP is alignment on how each new language feature fits together, complementing each other to create a more secure yet flexible system.
If we’re going to implement AuthAccount Capabilities, we’ll need a secure standard for the management of linked accounts. By enabling AuthAccount Capabilities, we’ll also need a mechanism limiting their issuance, or at minimum distinguishing that linking the signer’s account is possible in a given transaction. This problem can be satisfied by the proposed SuperAuthAccount (@bluesign) or similar hierarchical and/or role-based AuthAccount interfaces, restricting/enabling potentially dangerous actions within transactions. These actions would include linking accounts, adding/revoking keys, deploying contracts, etc. within a given transaction.
Capability Controllers (CapCons), if implemented, would increase auditability and provide granular control over AuthAccount Capabilities. The existence of AuthAccount Capabilities has design implications for CapCons’ implementation details; however, enabling AuthAccount Capabilities is not dependent on the existence of CapCons. In a world without this feature, we’ll want to consider how AuthAccount Capabilities are retrieved and revoked, particularly since they cannot be retargeted and because a user lacks knowledge of secondary party’s access, much less their identity.
The question of how and where these should rightly be integrated will be a key focus of community discussions.
Other open questions
There may be benefits to supporting multi-parenting of accounts, although this may also introduce complexities and edge cases that could be problematic or otherwise cause builders or users issues or concerns.
The role of the standard in offering utility functionality for working with child accounts
The conceptual exploration of the standard so far proposes a
ChildAccountManager contract resource which provides access to child accounts under its management. The question of whether it should expose utility methods for working with child accounts has obvious pros and cons. Utility functionality that wraps the linked account’s AuthAccount Capability raises source of truth problems and also scalability and performance concerns. An example of such a utility function would be a method that returns all NFT metadata from owned NFTs in a child account. Resolving which utility functions are justified and necessary will be essential.
Source of truth concerns
For reasons of performance and simplicity it seems worthwhile to avoid repetitious iteration over linked accounts to access their metadata. Leveraging structs to retain local copies of child account metadata for use by
ChildAccountManager introduces data synchronization considerations and questions relating to source of truth guarantees during runtime.
AuthAccount handling; by reference or capability?
The handling of child AuthAccount objects can be implemented in two ways; by reference, eg:
&AuthAccount or the stored
AuthAccount Capability. The latter introduces the risk of delayed attack vectors given that Capabilities can be copied and stored - a risk more prominent in a world without CapCons.
Object and type naming
The names for types and interfaces currently in use are best-effort but also need refinement so that they self-document and make sense to those learning about the standard.
The above list is not exhaustive but is representative of the main challenges still to be addressed on the path to an Account Linking standard. We expect to convene Cadence language breakout discussions to align and work through the resolution of these issues, as well as asynchronously through the FLIP PR.
There have been a number of requests to see use cases and examples showcasing why delegated AuthAccounts are even needed or useful and how builders might leverage them, so here it is. We’ve been exploring AuthAccount Capabilities in the flow-cli pre-release, and you can check out the work here:
Please check these examples out, play with them and leave your feedback below. We’re excited about the possibilities this brings to all the existing projects in the ecosystem and to Flow at large!
AuthAccount Capability implementation
Walletless Onboarding Blog Post