Add EIP: Ethereum Access Token

[ra-phael]

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

• The PR edits only existing draft PRs.
• The build passes.
• Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
• If matching on email address, the email address is the one publicly listed on your GitHub profile.

[eth-bot]

File EIPS/eip-7272.md

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

[abcoathup]

Suggested change

	eip: TBD
	eip: 7272

Assigning EIP number using PR number. Please also update the filename.

[ra-phael]

Done 👍

[github-actions]

The commit 05f51fe (as a parent of 1b97724) contains errors.
Please inspect the Run Summary for details.

[Yogi199501]

Nice work friends all went smoothly

[aa-eyup]

Great work! This is an elegant approach to a common problem. Just want to share there is a framework the Metamask team is working on called "Delegatable" (see github) that also tackles the general problem of authorization/access. Commonalities with this EIP include off-chain issuance of authorization, on chain validation, signed message validation, conditional invocation.

[danfinlay]

Thanks for pointing that out, @aa-eyup.

Key differences I see between this approach and Delegatable is that

1. these access tokens appear to allow flat authorization to call a given function to a single other account
2. these access tokens can only be granted by an EOA
3. these access tokens cannot then be re-delegated

Delegatable is already doing a few things beyond that:

1. Each delegation can support arbitrary attenuation (terms under which the function may be called), and users can even use their own smart contracts to write custom attenuation. An example is that a transfer() right can be attenuated to be a streaming payment right.
2. Not yet live in public prod, but we're working on support for contract accounts via EIP-1271, which seems forward-looking given the popularity of EIP-4337.
3. Under Delegatable, any holder of a delegation message (even a contract account implementing 1271) can re-delegate that right with additional attenuations, even without an on-chain transaction (as long as the EIP-1271 verifying contract supports counterfactual signatures, not needing any pre-transaction to set up valid state).

I really like the branding and pitch for EATs, and I don't doubt it can be useful in some situations, but I think that Delegatable aims to satisfy all the same use cases and also some more, so if you wanted to collaborate on that, I'd be happy to invite you to our discord.

[ra-phael]

Thank you @aa-eyup and @danfinlay for checking out this proposal!

I went through your great documentation on the Delegatable framework. I like how caveat enforcers allows developers to implement custom rules and the modularity provided is interesting. On the flip side, Delegatable seems more complex to reason about (e.g 10 different data structures vs 2 with EATs). The EAT system is more opinionated on purpose as it relates to security guarantees. For example from your docs:

Without any caveats the third-party has full permissions of the signing wallet.

From my understanding a delegate has full permission by default and this needs to be tone down with caveats whereas with EATs a delegate starts with no access by default, and the signer authorizes very specific function calls for a limited time.
It seems that EAT is like using Delegatable with some enforcers already baked-in: AllowedMethod + TimestampBefore + another caveat enforcer that would verify the content of calldata.
But something that appears orthogonal to our design choices with EAT is the difference you pointed out that

these access tokens cannot then be re-delegated

This is on purpose. For context on how we are using them, we are performing authentication of the person/entity behind an address before issuing an EAT. So the goal is for these EATs to be bound to the entity they’re given to. Although this is very difficult problem on its own, at least they are bound to the address of the recipient, who shouldn’t have the ability to pass on this authorization to someone else (without also giving control of their account).

We’ve also considered adding support for contract accounts via EIP-1271. Ultimately the signer needs to be an EOA but this would allow to rotate signers associated with a contract account in a "more standard way" than what we’re doing in KeyInfrastructure.sol.

[SamWilsn]

I am closing this pull request because we are in the process of separating EIPs and ERCs into distinct repositories. Unfortunately, as far as we are aware, GitHub does not provide any tools to ease this migration, so every pull request will need to be re-opened manually.

As this is a PR to create / modify an ERC, I will kindly ask you to redirect this to the new repository at ethereum/ERCs. We have prepared a guide to help with the process.

If there is relevant history here, please link to this PR from the new pull request.

On behalf of the EIP Editors, I apologize for this inconvenience.