Scoped AuthAccount Discussion

[austinkline]

Instructions

Please fill out the template below to the best of your ability and include a label indicating which tool/service you were working with when you encountered the problem.

Issue To Be Solved

AuthAccounts are dangerous. They are discouraged from being passed around but are the only way to configure accounts to accept resources. Because of that, dapps all have to determine how they should configure an account for a type of resource that they want to support. Marketplaces, for instance, must configure a purchaser's account for the NFT type they will receive or the purchase will fail.

Dapps should not need to know how to setup resources from other contracts. Each resource is different, and setting something up incorrectly could lead to the original application not working as intended. We need a mechanism that can be passed around to enable safely configuring accounts without risking a malicious contract compromising the entire AuthAccount.

(Optional): Suggest A Solution

I suggest we devise a protection mechanism to wrap AuthAccount types to control what a consumer of an AuthAccount can do, making it safe(er) to pass around. This ScopedAuthAccount would be given permission to access/modify only specific paths of the AuthAccount. With a mechanism like that, we could start to encourage NFT collections to create a setup method that takes this ScopedAuthAccount and configures it exactly as it is supposed to be. This puts the setup responsibility on creators of each resource to enumerate how they should be setup, taking the heavy-lifting away from dapps who have to make guesses on what to configure and what types to expose.

A ScopedAuthAccount would require all paths enumerated to it that it needs access to, any attempt to modify another path should panic. Below is a potential starting point, we could keep it to be only path based to make this as simple as possible (don't limit access to specific methods)

struct ScopedAuthAccount {
  let authAccount: AuthAccount

  // track which paths are permitted and which ones are not
  let permittedPaths: {Path: String}
  let canLink: Bool?
  let canBorrow: Bool?
  ...
  // other options to constrain access
  let canUnlink: Bool?

  // all the methods AuthAccount should be delegated to after asserting that the path can be accessed
  // for example:
  fun link<T: &Any>(_ newCapabilityPath: CapabilityPath, target: Path): Capability<T>? {
    pre {
      self.permittedPaths[newCapabilityPath] != nil && self.permittedPaths[newCapabilityPath]! == true: "access denied"
      self.canLink? == true: "access denied"
    }
    
    return self.authAccount.link<T>(newCapabilityPath, target: target)
  }
}

Scoping access would drastically reduce the blast radius of a malicious contract stealing an everything in an AuthAccount and could even go one step further and enforce ScopedAuthAccounts to be part of the prepare phase of a transaction. In that case, even those building transactions wouldn't have access to the entire account.

(Optional): Context

Flowty and many other marketplaces have an initialization issue. It leads to either:

1. Templated transactions to fill in the various parts of setup we need to do for a resource type
2. Not fully configuring something and only setting up the standard types, leaving the resource improperly configured and in need of fixing.

We are not in a position to properly configure NFT or FT collections ourselves because they might have non-standard links, resources such as NFT Collections are most capable of knowing how they themselves should be setup

[austinkline]

Great discussion today on this! To get a better idea of thoughts folks have on this issue, we will be getting a call together to discuss this problem down to one primary question:

"Who is responsible for setting up a resource in an account?"

The personas I see in play with regards to this question are:

• Users
• Wallets (Dapper Wallet, Blocto, Lilico)
• Contract Owners (Such as TopShot, Flovatar, etc)
• Dapps (Flowty, .find, Gaia, etc)

We will gather advocates for each persona to discuss this problem, as well as some other folks in Dapper who are familiar with this issue and come up with a solution to present to a wider audience. The soonest I will be around to discuss will be the 10th of October, I will reach out to folks and try to get something scheduled that week.

Once that is done, we can circle back to this or to a FLIP that @bjartek had drafted found here. Lastly, anyone reading this who wants to learn more about what was discussed can find notes here

[crash13override]

I agree that this would be a great feature to have! Having a simple and clear way of initializing wallets for each collection is a key part of the onboarding process and I think it needs to be addressed properly.