The implementation in PR #10 doesn't fully address concerns raised around regulatory risks incurred by dapps and other custodial parties in the case of unrestricted delegated access.
Up until recently, the idea was to give parent accounts unrestricted access to their linked accounts; however, feedback received thus far indicates that pattern creates potential regulatory concerns for custodial dapps, endangering the usability of this standard as an enabler for hybrid custody.
For example, a dapp having implemented walletless onboarding (i.e. acting as custodian on an account it created on behalf of a user) will want to support hybrid custody. If they give the user's non-custodial wallet unrestricted access on the dapp-custodied account - as the current implementation facilitates - the user could then configure & transfer FungibleTokens to the now linked dapp-custodied account. This would likely expose the dapp developers to regulatory risks they weren't prepared for or just don't want to deal with.
Suggest A Solution
One solution is to solve this problem via best practices in custodial handling upon linking. The custodian dapp might burn keys to the originally custodied account upon linking to a user's wallet while maintaining access to the dapp-related resources via Capabilities. This would mean minimal, if any, changes to the standard as is.
Another solution would be altering this standard to satisfy the following:
Introduce a notion of restricted/non-restricted account links
Explicit declaration of accessibility enabled by a link and necessary parent account acceptance of a provided link - i.e. a handshake of sorts
Enable the delegator to determine the accessibility on the child account such that changes to the accessibility require a new handshake between delegator & delegatee.
Restricted links can only access existing Capabilities at pre-defined paths, the retrieval of which must match a corresponding pre-defined Type.
Unrestricted provide the same sort of access available in current implementations, enabling parent accounts to do anything they'd normally do with their own accounts.
Include allowed paths & associated Capability types that can be accessed by parent accounts via restricted account links
Regardless of the path forward, we will likely want to remove the ability for parent accounts to grant Capabilities to linked child accounts as this introduces the potential for dapps to have access paths to FungibleTokens that, under current regulatory understandings around custodial obligations, would be undesirable by most dapps implementing hybrid custody via this standard.
Issue To Be Solved
The implementation in PR #10 doesn't fully address concerns raised around regulatory risks incurred by dapps and other custodial parties in the case of unrestricted delegated access.
Up until recently, the idea was to give parent accounts unrestricted access to their linked accounts; however, feedback received thus far indicates that pattern creates potential regulatory concerns for custodial dapps, endangering the usability of this standard as an enabler for hybrid custody.
For example, a dapp having implemented walletless onboarding (i.e. acting as custodian on an account it created on behalf of a user) will want to support hybrid custody. If they give the user's non-custodial wallet unrestricted access on the dapp-custodied account - as the current implementation facilitates - the user could then configure & transfer FungibleTokens to the now linked dapp-custodied account. This would likely expose the dapp developers to regulatory risks they weren't prepared for or just don't want to deal with.
Suggest A Solution
One solution is to solve this problem via best practices in custodial handling upon linking. The custodian dapp might burn keys to the originally custodied account upon linking to a user's wallet while maintaining access to the dapp-related resources via Capabilities. This would mean minimal, if any, changes to the standard as is.
Another solution would be altering this standard to satisfy the following:
Regardless of the path forward, we will likely want to remove the ability for parent accounts to grant Capabilities to linked child accounts as this introduces the potential for dapps to have access paths to FungibleTokens that, under current regulatory understandings around custodial obligations, would be undesirable by most dapps implementing hybrid custody via this standard.