Add ERC: Grant Permissions from Wallets

[pedrouid]

Adds JSON-RPC method for granting permissions from a wallet

[eip-review-bot]

File ERCS/erc-7715.md

Requires 1 more reviewers from @axic, @g11tech, @SamWilsn, @xinbenlv

[filmakarov]

Is this correct?

1. Why bob.sendTransaction? shouldn't it be alice.sendTransaction?
2. Why bob has interface of redeemDelegation? bob is Delegator, so it has ERC7710 interface with executeDelegatedAction method. redeemDelegation lives in the ERC7710Manager interface implemented by delegationManager.
   ERC-7710 for reference

[GregTheGreek]

just did a pretty big dive into this and can't really see concrete definitions with data in the context of policies. It also might make sense to try and define the permissions/policies deeper before getting into examples like these

[erensanlier]

I think there shouldn't be address field in native-token-transfer permission.

[SamWilsn]

The wording here is a bit awkward. How about:

Suggested change

	We define a new JSON-RPC method `wallet_grantPermissions` for DApp to request a Wallet to grant permissions in order to execute transactions on the user’s behalf. This enables two use cases:
	We define a new JSON-RPC method `wallet_grantPermissions`. With it, a DApp can request that a wallet grant permissions in order to execute transactions on the user’s behalf. This enables two use cases:

[SamWilsn]

Not sure if mermaid diagrams will render properly in Jekyll. If not, we have a slight preference for SVGs.

[SamWilsn]

I checked, and no, this will not render.

[eip-review-bot]

All Reviewers Have Approved; Performing Automatic Merge...

[aminhdev]

.

[moldy530]

any reason not to be consistent with permission and policies either both being an Array or both being singletons?

looking at some examples policies vs permissions below, it's also not super clear what the difference is between them. a NativeTokenSpendPolicy seems similar to an Erc20TokenTransferPermission. They both define limits on the spend of some funds.

[moldy530]

When I was first looking at this, I was thinking it would be used like:

{
  permission: { type: "owner" }, // or maybe "root" or "admin" type?
  policies: [], // no need to for policies because this is a root permission
}

or

{
  permission: { type: "session-key", data: { expiry: fifteenMinutesInMs } },
  policies: [
    ... // spend limits, etc
  ]
}

[VGabriel45]

Clicking ERC-7579 is giving 404.

Suggested change

	Example of formatting userOp signature using the [ERC-7679](./eip-7679.md) UserOp Builder
	Example of formatting userOp signature using the [ERC-7679](./erc-7679.md) UserOp Builder

[VGabriel45]

Clicking ERC-4337 and ERC-7679 is giving 404.

Suggested change

	`wallet_grantPermissions` replies with `permissionsContext` and `userOpBuilder` address inside the `signerMeta` field. DApps can use that data with methods provided by [ERC-7679](./eip-7679.md) to build the [ERC-4337](./eip-4337.md) userOp.
	`wallet_grantPermissions` replies with `permissionsContext` and `userOpBuilder` address inside the `signerMeta` field. DApps can use that data with methods provided by [ERC-7679](./erc-7679.md) to build the [ERC-4337](./erc-4337.md) userOp.

[VGabriel45]

Clicking ERC-7579 is giving 404.

Suggested change

	[ERC-7679](./eip-7679.md) UserOp Builder contract defines `bytes calldata context` parameter in all of its methods. It’s equivalent to the`permissionsContext` returned by the `wallet_grantPermissions` call.
	[ERC-7679](./erc-7679.md) UserOp Builder contract defines `bytes calldata context` parameter in all of its methods. It’s equivalent to the`permissionsContext` returned by the `wallet_grantPermissions` call.

[VGabriel45]

Suggested change

	- If a DApp leverages [ERC-7679](./eip-7679.md), it could use `permissionsContext` as the `context` parameter when interacting with the UserOp builder.
	- If a DApp leverages [ERC-7679](./erc-7679.md), it could use `permissionsContext` as the `context` parameter when interacting with the UserOp builder.

[VGabriel45]

Suggested change

	- If a DApp leverages [ERC-7710](./eip-7710.md), it could use `permissionsContext` as the `_data` when interacting with the delegation manager.
	- If a DApp leverages [ERC-7710](./erc-7710.md), it could use `permissionsContext` as the `_data` when interacting with the delegation manager.

[VGabriel45]

Suggested change

	`context` is a catch-all to identify a permission for revoking permissions or submitting userOps, and can contain non-identifying data as well. It MAY be the `context` as defined in [ERC-7679](./eip-7679.md) and [ERC-7710](./eip-7710.md). See “Rationale” for details.
	`context` is a catch-all to identify a permission for revoking permissions or submitting userOps, and can contain non-identifying data as well. It MAY be the `context` as defined in [ERC-7679](./erc-7679.md) and [ERC-7710](./erc-7710.md). See “Rationale” for details.

[VGabriel45]

Suggested change

	`accountMeta` is optional but when present then fields for `factory` and `factoryData` are required as defined in [ERC-4337](./eip-4337.md). They are either both specified, or none. If the account has not yet been deployed, the wallet MUST return `accountMeta`, and the DApp MUST deploy the account by calling the `factory` contract with `factoryData` as the calldata.
	`accountMeta` is optional but when present then fields for `factory` and `factoryData` are required as defined in [ERC-4337](./erc-4337.md). They are either both specified, or none. If the account has not yet been deployed, the wallet MUST return `accountMeta`, and the DApp MUST deploy the account by calling the `factory` contract with `factoryData` as the calldata.

[VGabriel45]

Suggested change

	`signerMeta` is dependent on the account type. If the signer type is `wallet` then it's not required. If the signer type is `key` or `keys` then `userOpBuilder` is required as defined in [ERC-7679](./eip-7679.md). If the signer type is `account` then `delegationManager` is required as defined in [ERC-7710](./eip-7710.md).
	`signerMeta` is dependent on the account type. If the signer type is `wallet` then it's not required. If the signer type is `key` or `keys` then `userOpBuilder` is required as defined in [ERC-7679](./erc-7679.md). If the signer type is `account` then `delegationManager` is required as defined in [ERC-7710](./erc-7710.md).

[github-actions]

The commit 23fa360 (as a parent of 57c37c6) contains errors.
Please inspect the Run Summary for details.

[SamWilsn]

Note to self: this is still blocked on #433.

---

I've locked this PR because too much of the discussion is technical in nature. Please discuss anything technical on the discussion thread.

---

Do not update the links to erc-xxxx.md as suggested above. That'll break our weird rendering system.