Consider allowing signed permission capabillity approvals in manifest by third parties

[ritave]

This issue talks about ZCAP-LD object capability framework both in how manifest permissions are expected to work and Metamask internals in which PermissionController is implemented. Understanding ZCAP-LD is a prerequisite.

Thinking about security, there's the issue of allowing anyone getting access to private key permission. This might cause less experienced Metamask users to be scammed out of their funds by them approving permissions they don't fully understand. There were some thoughts about disallowing access the Ethereum private keys, but I think a better solution would be to have an ability to delegate audits of a Snap.

In the system I'm thinking of, the author of a Snap, which requires private key access, would first have to request an audit of the Snap. We could use Gitcoin for that - the auditor would audit the Snap and then sign a permission approval for that Snap stating that the Snap with that specific shashum of sourcecode is to be trusted and can use those specific and highly sensitive permissions. Metamask would then verify the permission approval during Snap installation to automatically deny Snaps without a proper audit. In case the approval is correct, the user would still be asked for additional approval, but we could show an audited-checkmark similar to Twitter's verified checkmarks. To avoid sybil attacks, Gitcoin's ContributorRank and Activity metrics could be used to verify the quality of the auditor during installation.

Other sybil defenses could be considered, such as being a participant in specific DAOs such as the Moloch Dao, or participating in some kind of an Anti-Phishing DAO which would require buy-in. Or being part of Dan Finlay's proposed Anti-Phishing Web of Trust using Delegate smart-contract. Or some kind of weighted average of multiple metrics.

To ensure full chain of security, this issue should interact with #413.

[ritave]

A simplified way to discourage scammers would be to use the sybil defense score directly to the Snap developer themselves. Scammers would be added to the main phishing list in Metamask and recreating the Snap with a new identity would be costly.

[ritave]

Another idea proposed by @danfinlay would be to have a decentralized signature authority chain required for certyfing Snaps using Delegate smart contract

[danfinlay]

Another dimension we can stack on top: Key access methods may simply expose cryptographic functions, but not pass key material to the snap. This creates a firm guarantee that keys cannot be stolen. On top of that, the various mechanisms above could be used to decide "which snaps can even ask for access to these cryptographic methods", and then once they can, the user gets to review the permissions and decide for themselves.

So that's three layers of safety (not bad!):

• A very manual layer of confining key material to the wallet if possible.
• A certification process for being able to request cryptographic methods
• User informed consent to expose their keys to any third party.

[danfinlay]

Also, if we allowed signed approvals, I might suggest these approvals don't need to be part of the manifest, they can be part of the addSnap method, since many different approval chains may authorize a snap as credible, and just because one chain is revoked doesn't mean the whole snap might need to be re-published.