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.

[louisguitton]

impressive work 👏 the demo during the hackathon was really interesting and I'll need to find the time to properly read through this. For now I've found this typo.

[louisguitton]

Suggested change

	- [Standardizing child accounts’ resources access](#standardizing-child-accounts-resources-access)
	- [Storage Iteration Convenience Methods](#storage-iteration-convenience-methods)

[highskore]

I think having the originating publicKey as one of the params in the Account Creation events would be very beneficial.

[highskore]

Something like

pub event ChildAccountCreatedFromManager(parent: Address, child: Address, originatingPublicKey: String)
pub event AccountCreatedFromCreator(creator: Address?, newAccount: Address, originatingPublicKey: String)

[sisyphusSmiling]

That's a good suggestion. I believe you raised the issue in the Open House yesterday - would this event data allow dApps to determine the relevant creation event?

[highskore]

Yea I did raise it yesterday, I think a combination of the creator address, which you already specified, and the originatingPublicKey would allow dApps to determine the events that they care about.

[sisyphusSmiling]

Great, thanks for the helpful feedback! I'll add this now

[highskore]

Isn't this a cadence anti-pattern?

Is this field really necessary if people can already query the events to find out which account has created which children?

I can imagine after a dApp creates a big number of accounts, this dictionary will not be able to take new inputs. So we would need this to be sharded or it's not really scalable.

[sisyphusSmiling]

That is definitely a concern. It served as an intermittent solution for the walletless demo, but we weren't sure if it would be helpful long-term. Since the inclusion of the Creator is an open question and not critical to account linking, this detail might imply we remove it from the standard.

[joshuahannan]

Since the parent accounts are managing entire accounts, then I don't think that it is wrong to store a list of the addresses it controls since it does literally control the entire address and account addresses can't be changed

[highskore]

@sisyphusSmiling Right, that's very true, imo it would be a much cleaner solution if the ChildAccount contract did not include any account creation methods at all, and only have the Child -> Parent account linking features.

Then the dapps/users could handle account creation in their own custom ways and only use the ChildAccount contract for the purpose of linking and managing child(parent) accounts.

[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 - FLIP for entitlements and safe reference downcasting #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:

[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.

[joshuahannan]

Since the parent accounts are managing entire accounts, then I don't think that it is wrong to store a list of the addresses it controls since it does literally control the entire address and account addresses can't be changed