ERC-7715: Grant Permissions from Wallets

ERCs
1

Adds JSON-RPC method for requesting permissions from a wallet

https://github.com/ethereum/ERCs/pull/436/

8 Likes
2

In the context of this ERC, How does wallet identify a DApp and ensure it was still the same DApp? It seems to me there are some implied assumptions that i might not know and probably better spell out.

If the assumption is that DApp maintains a secure connection with wallet, that shall be spelled out and investigated I think. For example, a hardware wallet could be connected to an offline DApp that only signs TX signature and be distributed in less common ways

1 Like
3

Is there still active work on this proposal? One question I have: this standard defines an expiry for the session end time, but I’m thinking providing an additional constraint on the start time would be useful. Similar to how we have validAfter and validUntil in ERC-4337. Thoughts?

1 Like
4

@jayk Its being actively worked on. Do you think validAfter should be at the top level request? IMO Its more fitting in the specific permission like this:

 permissions: [
          {
            type: 'native-token-transfer',
            data: {
                allowance: '0x1DCD6500',
                validAfter: 1737550474
            }
          }
        ],
5

Thanks for the response! Curious - what would be the use case for being able to specify different validAfters for different permissions? Would we also want to specify different validUntils for each as well then?

In the context of session keys, it seems simpler to think about a valid range at the key level, during which all of the permissions it has been granted is valid. Put another way, this would be equivalent to having time range be an additional permission which must be checked for each action. This is how Alchemy and ZeroDev do it today, with TimeRangeModule and TimestampPolicy, respectively.

6

If you check out the 7715 spec, currently we have RateLimitPermission for example in the spec. I think ZeroDev and Alchemy would map their permissions to a top level ones.
validUntil is the expiry and validAfter can be modeled as a separate permission.

7

Given the fact that crypto assets are usually very volatile, would there be a way to update the permissions on the go?

1 Like
8

The 7715 spec is a significant value add to the wallet layer. However, during the implementation of the first iteration in MetaMask, I encountered a few pain points that I believe could hinder broader adoption.

I’ve opened a PR against the spec proposing some minor modifications to help make the standard more manageable for wallet implementations.

Feedback is welcome!

1 Like
9

ERC-7715 describes the PermissionResponse as being a (presumably TypeScript-like) union of the PermissionRequest type with additional properties. A PermissionRequest is a list of objects. Is it the author’s intention here to make the PermissionRequest a list of objects, as well? See the following for an excerpt from the document:

type PermissionRequest = {
  chainId: Hex; // hex-encoding of uint256
  address?: Address;
  expiry: number; // unix timestamp
  signer: {
    type: string; // enum defined by ERCs
    data: Record<string, any>;
  };
  permissions: {
    type: string; // enum defined by ERCs
    data: Record<string, any>;
  }[];
}[];
// union of list and properties
type PermissionResponse = PermissionRequest & {
  context: Hex;
  accountMeta?: {
    factory: `0x${string}`;
    factoryData: `0x${string}`;
  };
  signerMeta?: {
    // 7679 userOp building
    userOpBuilder?: `0x${string}`;
    // 7710 delegation
    delegationManager?: `0x${string}`;
  };
};
1 Like