Scoped AuthAccount Discussion

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

Start by locating the existing AuthAccount implementation and the transaction prepare-phase behavior referenced in the issue; no files or tests are named. Review how account paths and resource setup are currently handled, then define the ScopedAuthAccount scope and safety rules. Done means the design is agreed and its permitted and denied access behavior is covered by focused tests.