Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add ERC: Embedded Accounts as Smart Modules #100

Closed
wants to merge 6 commits into from
Closed

Add ERC: Embedded Accounts as Smart Modules #100

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
f2bd7fe
adds sso plugin
GregTheGreek Nov 10, 2023
9277975
Update ERCS/erc-XXXX.md
GregTheGreek Nov 10, 2023
9d13468
update eip mumber
GregTheGreek Nov 10, 2023
bdfec34
update numbers
GregTheGreek Nov 10, 2023
2b39d89
delete old
GregTheGreek Nov 10, 2023
8ec0914
Update ERCS/erc-7556.md
GregTheGreek Nov 10, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
157 changes: 157 additions & 0 deletions ERCS/erc-7556.md
View file
Open in desktop
@@ -0,0 +1,157 @@
---
eip: 7556
title: Embedded Accounts as Smart Modules
description: TODO
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'll need something here, even if it isn't your final description.

For inspiration: What's an embedded account? Smart module? Who might want to use this proposal?

author: Alexander Müller (@alexmmueller), Gregory Markou (@GregTheGreek)
discussions-to: https://ethereum-magicians.org/t/erc-7556-embedded-accounts-as-smart-modules/16537
status: Draft
type: Standards Track
category: ERC
created: 2023-11-10
requires: 6900, 7555

Check failure on line 11 in ERCS/erc-7556.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

unable to read file `erc-7555.md`: Io: JsValue(Error: ENOENT: no such file or directory, open 'ERCS/erc-7555.md' Error: ENOENT: no such file or directory, open 'ERCS/erc-7555.md') 

error[preamble-requires-status]: unable to read file `erc-7555.md`: Io: JsValue(Error: ENOENT: no such file or directory, open 'ERCS/erc-7555.md'
Error: ENOENT: no such file or directory, open 'ERCS/erc-7555.md')
  --> ERCS/erc-7556.md:11:16
   |
11 | requires: 6900, 7555
   |                ^^^^^ required from here
   |
   = help: see https://ethereum.github.io/eipw/preamble-requires-status/
---

## Abstract
This proposal extends [ERC-xxxx](./ERC-xxxx) to add a new request method allowing applications to register an embedded wallet as [ERC-6900](./ERC-6900) plugin.

## Motivation
Building off of [ERC-xxxx](./ERC-xxxx), we define a request that allows an application to register an embedded wallet against a users main smart wallet.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Building off of [ERC-xxxx](./ERC-xxxx), we define a request that allows an application to register an embedded wallet against a users main smart wallet.
Building off of [ERC-xxxx](./ERC-xxxx), we define a request that allows an application to register an embedded wallet against a user's main smart wallet.


The user experience of using a smart account has been dramitically improved with the inclusion of alternative signing methods (such as passkey), but have opened up a few poorer experiences. When an application needs a user to signoff on an a message, to be included via a paymaster, that user needs to access the original signing key that is the owner of the smart account. In a mobile setting, this could be very cumbersome, and include switching contexts (between windows, screens, or apps) in-order to achieve that. Many developers have opted for centalized solutions to manage all the key operations, or simply adding new credentials (such as embedded wallets) as an owner to the smart wallet.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo in dramitically


This poses many security concerns for an end user. If a user interacts with two mobile apps, both levereging embedded wallets, and both wallets are added to the smart wallet as owners, the possibility of funds being stolen is high. A malicious app could have an embedded wallet registered on a user wallet, and simply manually drain the account, since they can manipulate the user into signing a malicious payload, or the app simply has access to the private key.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this true for any wallet? Is the point that the more wallets you use simultaneously increases that risk? Eg with an EOA I can use MetaMask, Rainbow, ... all with the same private key

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but I would say there is a fundamental difference between sharing a privatkey between wallets, and adding many owners with "sudo" to a smart contract wallet

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To add a new owner to a SA, dApp (game) will require the user to sign at least one userOp with the original signing key.
So, dApp should find a way for a user to access the original signing key in any case, right?

Instead of adding an owner with 'sudo', a session key with a limited validity timeframe and limited permissions can be added at this point.


Leveraging ERC-6900, and ERC-xxxx a developer can make a request to register the plugin, passing along the embedded wallet and scoped permissions.

These permissions can be quite restrictive, only allowing the embedded wallet to spend a certain amount of a token, a certain amount per day or week, or only interact with certain addresses.

This standard aims to achieve:
1. Standard way for applications to register a plugin back to a known smart wallet.
2. A way for embedded wallets to act as restrictive signers to an existing smart wallet.

## Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

### Definitions
- **Smart account** - An ERC-4337 compliant smart contract account that has a modular architecture.

Check failure on line 36 in ERCS/erc-7556.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

the first match of the given pattern must be a link 

error[markdown-link-first]: the first match of the given pattern must be a link
  --> ERCS/erc-7556.md
   |
36 | - **Smart account** - An ERC-4337 compliant smart contract account that has a modular architecture.
   |
   = info: the pattern in question: `(?i)(?:eip|erc)-[0-9]+`
   = help: see https://ethereum.github.io/eipw/markdown-link-first/
- **Domain** - A string of text acting as an identification to a server or wesbite (eg: `ethereum.org` or `ABCDE12345.com.example.app`).
- **EOA** - Accounts that are controlled by private keys.
Comment on lines +37 to +38
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two aren't used in the specification fyi

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead, I would add the definition of an Embedded Wallet

- **Provider** - A third party service provider that is able to authenticate a user and produce a keypair for the user.

### Register Plugin Redirect
An application should make a redirect call to a given provider, with all the necessary parameters needed to register a plugin, per the method `installPlugin` defined in ERC-6900.

As defined in ERC-6900, the `pluginInitData` parameters must include the embedded wallet `public_address` that is authorized to sign transaction on-behalf of the smart wallet. The format to which the `pluginInitData` is formatted does not matter, since the 6900 plugin should have that well defined, otherwise the transaciton will revert.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo in transaciton


#### Schema
##### Request
```=
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same kinda comment here as the other one: specify what language the schema is written in.

parameters:
- in: query
name: redirect_uri
schema:
type: string
description: The uri that the provider should redirect back to.
- in: query
name: smart_account_address
schema:
type: string
description: The address of the smart account where the plugin is being registered against.
- in: query
name: chain_id
schema:
type: string
description: The chain_id of a given netowrk.
- in: query
name: plugin_address
schema:
type: string
description: The address of the ERC-6900 plugin.
- in: query
name: manifestHash
schema:
type: string
description: The hash of the plugin manifest.
- in: query
name: pluginInitData
schema:
type: string
description: The data to be decoded and used by the plugin to setup initial plugin data for the modular account. At a minimum this must include the embedded wallet's public address.
- in: query
name: dependencies
schema:
type: string
description: The dependencies of the plugin, as described in the manifest.
- in: query
name: injectedHooks
schema:
type: string
description: Optional hooks to be injected over permitted calls this plugin may make.
```

##### Response
```=
parameters:
- in: query
name: result
schema:
type: boolean
description: Returns a true if the plugin was successfully registered.
- in: query
name: plugin_address
schema:
type: boolean
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

string

description: The address of the ERC-6900 plugin that was registered.
- in: query
name: smart_account_address
schema:
type: boolean
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and string

description: The address of the smart account where the plugin was registered.
```

#### Syntax
##### URI Request Syntax
```=
https://<PROVIDER_URI>/
redirect_uri=<YOUR_REDIRECT_URI>
&smart_account_address=<USER_SMART_ACCOUNT>
&plugin_address=<PLUGIN_ADDRESS>
&manifest_hash=<MANIFEST_HASH>
&plugin_init_data<PLUGIN_INIT_DATA>
&dependencies=<DEPENDENCIES>
&injected_hooks=<INJECTED_HOOKS>
```

##### URI Response Syntax
```=
https://<YOUR_REDIRECT_URI>?
result=<RESULT_BOOLEAN>
&plugin_address=<PLUGIN_ADDRESS>
&smart_account_address=<SMART_ACCOUNT_ADDRESS>
```

## Rationale
#### Application
##### Initial Request
An application must provide all relevant information that is required to successfully call `installPlugin` per ERC-6900, the `smart_account_address` and the `chain_id` are added to the request to ensure the plugin is install on the correct smart account. Using ERC-XXXX a developer would have already discovered the `smart_account_address` of a given user.

##### Response from provider
An application simply needs to check the result of the request, and act on it accordingly.

#### Provider
Upon parsing all the relevant data, it is the providers job to correctly attempt to install the plugin, if it fails do so, the interface should alert the user why it was not able to do so. If the plugin is already installed, the provider should simply return successfully.

## Backwards Compatibility

No backward compatibility issues found.

## Reference Implementation
// TODO
Comment on lines +148 to +149
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## Reference Implementation
// TODO
<!--
## Reference Implementation
// TODO
-->

The reference implementation section isn't mandatory, so you can just comment it out.


## Security Considerations

Needs discussion.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Needs discussion.
<!-- Needs discussion. -->


## Copyright

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