[Deprecated] Improve CaveatBuilders to be less risky #20
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
📝 Description
This changes how a developer interacts with CaveatBuilders in order to reduce the risk of signing delegations with insufficient attenuation.
🔄 What Changed?
List the specific changes made:
allowEmptyCaveats
toallowInsecureUnrestrictedDelegation
allowInsecureUnrestrictedDelegation
not just when creating a CaveatBuilder, but also when creating, and when signing a DelegationcreateCaveatBuilder
moved from root export to/utils
callData
tocalldata
in the ExactCalldata terms builder🚀 Why?
Even with the
allowEmptyCaveats
flag, there is a high risk of developers creating delegations with less attenuation than they expect. Because of this, we have made two general changes:It's not much harder to accidentally create empty caveat collections, because the configuration flag is more likely to stand out as a problem, because of it's name. It is now required with creating and signing delegations, which will capture cases when the
CaveatBuidler
interface is not used, and generally introduces more friction to high risk full authority delegations.Instead of a developer starting with Full Authority, and attenuating that through addition of Caveats, a developer now starts with a "Unit of Authority", which constrains the delegation to interact with a native token, erc20, erc721, ownership, etc, with specific constraints out of the box. The developer may then further attenuate the permission.
🧪 How to Test?
There is reasonable amount of coverage of this new behaviour. A test dapp could be created that creates delegations using these new UnitOfAuthority factories, such as:
List any breaking changes:
No breaking changes
Breaking changes (describe below):
CaveatBuilder now accepts config object for all caveat types
CaveatBuilder may no longer be imported from the root export, but now from the
/utils
export (we should encourage use of the UnitOfAuthority caveat builder factories.@metamask/delegation-core terms builder now accepts
calldata
parameter, rather thancallData
(but this is unreleased, so maybe doesn't count).📋 Checklist
Check off completed items:
🔗 Related Issues
Link to related issues:
Closes #
Related to #
📚 Additional Notes
Any additional information, concerns, or context: