Skip to content

Commit

Permalink
Update erc-7715.md
Browse files Browse the repository at this point in the history
  • Loading branch information
@pedrouid
pedrouid authored May 26, 2024
1 parent 4b4c279 commit 9b592d2
Showing 1 changed file with 14 additions and 15 deletions.
29 changes: 14 additions & 15 deletions ERCS/erc-7715.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL

### `wallet_issuePermissions`

We introduce a `wallet_issuePermissions` method for the DApp to request permissions from the wallet. We’d prefer `wallet_requestPermissions` but it’s already taken with [EIP-2255][EIP-2255].
We introduce a `wallet_issuePermissions` method for the DApp to request permissions from the wallet. We’d prefer `wallet_requestPermissions` but it’s already taken with [ERC-2255](./eip-2255.md).

#### Request Specification

Expand Down Expand Up @@ -133,11 +133,11 @@ type IssuePermissionsResponse = {
- `grantedPermissions` is a list of permissions that were granted. The wallet MUST grant `required` permissions if the request was approved.
- `expiry` is the expiry time that was granted. The wallet MAY grant a different expiry time than the one that the DApp requested.
- `factory` and `factoryData` are as defined in ERC-4337. They are either both specified, or none. If the account has not yet been deployed, the wallet MUST return `factory` and `factoryData`, and the DApp MUST deploy the account by calling the `factory` contract with `factoryData` as the calldata.
- `factory` and `factoryData` are 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 `factory` and `factoryData`, and the DApp MUST deploy the account by calling the `factory` contract with `factoryData` as the calldata.
- `~~sessionId` is an optional field that identifies the session if no `signer` was specified in the request. See “Wallet-managed Sessions” for details.~~
- `permissionsContext` is an opaque string that identifies the session. It MAY be the `context` as defined in ERC-7679 and ERC-7710. See “Rationale” for details.
- `permissionsContext` is an opaque string that identifies the session. It MAY be the `context` as defined in [ERC-7679](./eip-7679.md) and [ERC-7710](./eip-7710.md). See “Rationale” for details.
If the request is malformed or the wallet is unable/unwilling to issue permissions, wallet MUST return an error with a code as defined in [EIP-1193](https://eips.ethereum.org/EIPS/eip-1193#provider-errors).
If the request is malformed or the wallet is unable/unwilling to issue permissions, wallet MUST return an error with a code as defined in [ERC-1193](./eip-1193.md).
`wallet_issuePermissions` response example:
Expand Down Expand Up @@ -252,7 +252,7 @@ type RateLimitPermission = {
### Wallet-managed Sessions
If `signer` is not specified in the request, the wallet manages the session. If the wallet approves the request, it MUST accept ERC-5792’s `wallet_sendCalls` with the `permissions` capability, which MAY include the `permissionsContext`. For example:
If `signer` is not specified in the request, the wallet manages the session. If the wallet approves the request, it MUST accept [ERC-5792](./eip-5792.md)’s `wallet_sendCalls` with the `permissions` capability, which MAY include the `permissionsContext`. For example:
```tsx
[
Expand Down Expand Up @@ -285,7 +285,7 @@ Upon receiving this request, the wallet SHOULD send the calls in accordance with
### Capabilities
If the wallet supports [EIP-5792][EIP-5792], wallet SHOULD respond on **`wallet_getCapabilities`** request using the `permissions` key.
If the wallet supports [ERC-5792](./eip-5792.md), wallet SHOULD respond on **`wallet_getCapabilities`** request using the `permissions` key.
The wallet SHOULD include `signerTypes` (`string[]`) and `permissionTypes` (`string[]`) in the response, to specify the signer types and permission types it supports.
Example:
Expand Down Expand Up @@ -321,11 +321,11 @@ Example:
#### ERC-7679 with `Key` type signer
`wallet_issuePermissions` replies with `permissionsContext` and `userOpBuilder` address inside the `accountMeta` field. DApps can use that data with methods provided by ERC-7679 to build the ERC-4337 userOp.
`wallet_issuePermissions` replies with `permissionsContext` and `userOpBuilder` address inside the `accountMeta` field. DApps can use that data with methods provided by [ERC-7679](./eip-7679.md) to build the [ERC-4337](./eip-4337.md) userOp.
ERC-7679 UserOp Builder contract defines `bytes calldata context` parameter in all of its methods. It’s equivalent to the`permissionsContext` returned by the `wallet_issuePermissions` call.
[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_issuePermissions` call.
Example of formatting userOp signature using the ERC-7679 UserOp Builder
Example of formatting userOp signature using the [ERC-7679](./eip-7679.md) UserOp Builder
```jsx
const getSignature = async ({ address, userOp, permissionsContext }: GetSignatureArgs) => {
Expand Down Expand Up @@ -368,19 +368,21 @@ sequenceDiagram

#### ERC-7710

TODO

## Rationale

Frequent user approvals hinder DApp innovation. This EIP introduces `wallet_issuePermissions`, a method for DApps to request permission from wallets. By requesting permissions in advance, DApps can enable smoother user experiences for functionalities like subscriptions and automated trading. This approach simplifies user interaction and fosters the development of richer DApps, ultimately accelerating blockchain adoption and greatly improve user experience.
Frequent user approvals hinder DApp innovation. This ERC introduces `wallet_issuePermissions`, a method for DApps to request permission from wallets. By requesting permissions in advance, DApps can enable smoother user experiences for functionalities like subscriptions and automated trading. This approach simplifies user interaction and fosters the development of richer DApps, ultimately accelerating blockchain adoption and greatly improve user experience.

### PermissionsContext

The `permissionsContext` field serves a critical role in ensuring the security and validity of user operations (UserOps) constructed by DApps to leverage the permissions. It contains all the information that is required to properly build the userOp according to Smart Account vendor’s specific rules.

If DApp leverages ERC-7679, it should send `permissionsContext` as the `context` parameter for the methods of ERC-7679 compliant UserOp builder. UserOp builder will then use `permissionsContext` to format userOp.
If DApp leverages [ERC-7679](./eip-7679.md), it should send `permissionsContext` as the `context` parameter for the methods of [ERC-7679](./eip-7679.md) compliant UserOp builder. UserOp builder will then use `permissionsContext` to format userOp.

For example, `permissionsContext` will in most cases contain the signature issued by Smart Account owner over some Permission Object. UserOp builder will include this into userOp. Smart Account then uses this signature during userOp validation to make sure the permissions were granted by an authorized party.

Wallets should include the minimal amount of data inside `permissionsContext` that will allow the DApp to build and verify the ERC-4337 UserOp in combination with signatures from the requested signers.
Wallets should include the minimal amount of data inside `permissionsContext` that will allow the DApp to build and verify the [ERC-4337](./eip-4337.md) UserOp in combination with signatures from the requested signers.

### Multiple Key Signers

Expand All @@ -407,6 +409,3 @@ Malicious DApps could pose as legitimate applications and trick users into grant
## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).

[EIP-2255]: https://eips.ethereum.org/EIPS/eip-2255
[EIP-5792]: https://eips.ethereum.org/EIPS/eip-5792

0 comments on commit 9b592d2

Please sign in to comment.