Consider allowing signed permission capabillity approvals in manifest by third parties

This issue talks about [ZCAP-LD object capability framework](https://w3c-ccg.github.io/zcap-spec/) both in how manifest permissions are expected to work and Metamask internals in which [PermissionController](https://github.com/MetaMask/controllers/blob/654e5dc5641fb93dc9b2c95463baa493e3579023/src/permissions/PermissionController.ts) 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](https://github.com/danfinlay/delegatable-eth). Or some kind of weighted average of multiple metrics.

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

Start by reading the ZCAP-LD specification and the referenced PermissionController.ts implementation, then review issue #413 for the related security requirements. The issue proposes third-party signed approvals, auditor verification, and installation-time checks, but it does not define a bounded entry point, test plan, or acceptance criteria, so the intended design must be clarified before implementation.

Written by the indexing model from the issue text.