FLIP - AuthAccount Capabilities Management Standard

[sisyphusSmiling]

Forum Post: https://forum.onflow.org/t/account-linking-authaccount-capabilities-management/4314

This FLIP introduces a proposed standard for how AuthAccount Capabilities are managed and brings into discussion a number of open questions around the topic of account linking.

[sisyphusSmiling]

Quick update on this to everyone following along. Based on the feedback received so far, I'm working to include the following changes in the next iteration of this contract:

• NFT, MetadataViews, and ViewResolver standards implementation
• Add updated events with suggested event data
• Removal of account creation methods, leaving account creation up to dApps
• Encapsulate associated resources for more fine grained access control
• Verbiage change from ChildAccount to LinkedAccounts
• Remove ChildAccountCreator resource

My plan is to get this implementation done and reflected in this FLIP by EOD today. If interested, you can follow along in this branch of the onflow/linked-accounts repo

[sisyphusSmiling]

Quick update on progress over the week as it's not visible in the contents of this FLIP:

We responded to concerns raised by community developers related to sharing user-controlled access on app-custodied accounts. The proposed solution builds on this FLIP, though works to separate concerns between user and developer side of the house with this FLIP solving the user side of the equation.

Essentially, the proposed solution, outlined in this forum post, enables developers to define restricted access on the linked account which takes effect in the same transaction which links user and app accounts. The user then has unrestricted access while the app retains access to only the Capabilities needed to act on behalf of the user in the context of the dapp.

Moving forward, the focus for this week is increasing test coverage of the implementation contract & supporting transactions to ensure sound security. Additionally, I'll be working to break down concepts related to account linking & hybrid custody that will help devs get up to speed quickly.

Please check out the linked forum post, appreciate it all!

[sisyphusSmiling]

Adding another quick update here now that we've aligned on an access model:

After lots of great discussion, the proposal for an unrestricted user/restricted app access model is being flipped in favor of a restricted user/unrestricted app access model. Check out the flowtyio/restricted-child-account repo for work implementation level details and work on this front moving forward.

This is due to a number of factors including:

• prioritizing ease of app implementation
• minimizing potential foot guns for app developers
• interoperability with existing app custodial infrastructure and common practices
• need to return Typed Capabilities (very cool work with @austinkline's CapabilityFactory to enable this)

You can find the discussion in the previously linked forum post and meeting notes.

Remaining open questions:

• Specifics around event data emitted
• Rules around multi-tenancy (IOW managing multiple parents & rule sharing)
• Planning for upgradability with upcoming AuthAccount entitlements - #54 (cc: @turbolent @dsainati1)
• Decide how we want to handle access promotion from restricted -> unrestricted user access

Next steps:

• Update this FLIP with new access model overview
• Feedback and iteration on HybridCustody contract PR
• Submit PR with suggested events as conversation point on the issue

[austinkline]

Thanks for the added summary @sisyphusSmiling! Adding some notes about the current PR as it pertains to outstanding issues

Rules around multi-tenancy (IOW managing multiple parents & rule sharing)

How it works in the active PR is that a ChildAccount resource creates and manages underlying ProxyAccount resources which each have their own rules managed by the account's owner. Parents are shared a capability to a proxy only meant for them. Even if the mechanisms in place are complex, the owner of the child account only needs to know about a few methods to add, revoke, or edit existing parents (edits aren't done yet)

Decide how we want to handle access promotion from restricted -> unrestricted user access

The ChildAccount has a few methods to change an account's ownership which would then alter restricted -> unrestricted access. Mainly, there are two forms of modified ownership:

1. Transferred Ownership - The current owner of a child account gives ownership of the account to another wallet. This will revoke all outstanding keys on the wallet, unlink all existing AuthAccount capabilities, and make a new one for existing parent/child accounts to keep operating as usual. The new owner gets a capability to the ChildAccount which they can then access as they please. This will give them the full AuthAccount capability which means they have unrestricted access
2. Relinquished Ownership - Needs a new name, probably. But the idea here is that no one fully owns the account. An unowned account could be jointly shared between two parents but neither can change the access another one has.

Here is a diagram for how the current PR works:

[btspoony]

Some thoughts and implementation from my side.

https://github.com/onflow/hybrid-custody/pull/140

Feel free to further discuss.

[sisyphusSmiling]

FYI This FLIP has been updated to reflect the current state of HybridCustody contracts currently deployed to Testnet and proposed for Mainnet.

Please take a look and leave your thoughts/reviews.