Thanks so much for the thoughtful feedback and helpful resources @kate_sills!
A few follow up comments & questions…
-
You’re right, there’s not a way to aggregate a user’s dapp created accounts until the user creates a primary, wallet-managed account. Thanks for pointing that out, this should be clarified in the docs.
-
I was actually hoping to get some feedback on this from you, so thanks for bringing this up! Truthfully, I’m torn. Your point about “don’t prohibit what you can’t prevent” is valid. On one hand, I can see how attempting to restrict malicious usage of a Capability by limiting access via reference is an incomplete safeguard. On the other hand, if we allow access to Capabilities as they currently exist we lose an audit trail for who has access to those Capabilities. In your example between Alice & Bob, the key there is “as long as the access through the copy still is attributed to Bob”. The way I understand it, Capabilities aren’t currently attributable in this manner. Using Capabilities as they exist today, I can link an AuthAccount Capability at
/private/AuthAccountand give that to Alice. Let’s say Alice stores it in some resource. Alice can then call a getter for the Capability and give it to Bob. I have no way to know that Bob now has that Capability and moreover, presented with both, they’re indistinguishable from each other (that is until CapabilityControllers are finalized). Further, if I want to revoke Bob’s access I have to also revoke Alice’s access by unlinking the Capability at that path. This is driven by two factors it seems will be addressed in CapCons - 1/ Capabilities linked at the same path are indistinguishable from each other and 2/ revocation of Capabilities linked at the same path requires unlinking both at the source, making more granular revocation impossible. The question then is, if I can’t distinguish copied Capabilities from those I issued, how can I create auditability in the construction of delegated account access via these Capabilities to prevent someone from inadvertently copying one I have access to? The most apparent (and perhaps naive) answer for me is to encapsulate the underlying Capability and allowing access by reference, restricting copied Capabilities altogether. Is my thinking about this considering the limitations of Cadence’s Capabilities sound here? -
Petnames are a good callout. My concern here is around storage usage. With the aforementioned NFT implementation, the resource holding all linked account representations would require a third mapping to support petnames on linked accounts
{String: Address}. I wonder if it would be possible to implement petnames off-chain, say at the wallet layer
Aside from portability, is there a reason we would prefer petnames to be on-chain? I have considered the phishing vector, and for now my solution has been to limit addition of linked accounts to private access. I think there might be an off-chain solution to prevent these sorts of phishing attacks - event emission on adding a linked account + wallet notification on addition of a linked accounts, perhaps even a list of verified originating accounts + attached signatures on creation (though I guess that’s not very storage efficient), etc. Back to petnames, if you/others feel the storage (and scalability by extension) cost is worth the convenience/added security, I don’t see why it couldn’t be added. -
What you describe here is the ideal state! Unfortunately, the custodial party has ultimate authority of the child account. So, if a dApp creates an account to support walletless onboarding and later delegates access to the user’s wallet account, the dApp still has full signatory authority over that account. The user can do things with the account - they can even revoke the dApp’s key. But so long as the user still wants to share account access with the dApp, there’s currently no way to downgrade the dApp’s access. So you can see there is certainly a degree of trust involved in this construction, and I’ve struggled to figure out how to minimize with the current Cadence constructs & feature set. If you have further thoughts on this I’m all ears!
P.S. there’s a new version of this standard in PR here implementing the NFT & MetadataViews standards. Updates to the FLIP will follow by EOD Monday. Thanks again all for the input & feedback so far!