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

Session Keys on Ten Gateway #2024

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Session Keys on Ten Gateway #2024

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
3abdccc
Create session_keys_on_ten_gateway.md
tudor-malene Aug 14, 2024
def745c
Update session_keys_on_ten_gateway.md
tudor-malene Aug 14, 2024
f5b62f0
Update session_keys_on_ten_gateway.md
tudor-malene Aug 15, 2024
e54d8cf
Update session_keys_on_ten_gateway.md
tudor-malene Aug 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 64 additions & 0 deletions design/ux/session_keys_on_ten_gateway.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
# Session keys on Ten

EIP-4337 (Account Abstraction) has popularised the "Session keys" concept to minimize clicks.

We want to offer a similar user-friendly experience to Ten dApp devs.

To test the concept, we will convert the Battleships game to a no-click UX.


## The Ten Gateway as a Session Key manager

*Reminder: A session key (SK) is a key that is not managed in a wallet and can be used to sign behind-the-scenes operations without user action.*

Without smart contract wallets, a SK must have a balance to pay for gas.

The browser can manage SKs on behalf of the user, but it can lose the gas if the browser crashes.


The TG already manages VKs on behalf of users, so adding SKs is relatively straightforward.

The advantage of the TG managing SKs is that it can return the funds to the EOA anytime.

Another advantage is that they can be reused between sessions to avoid unnecessary transactions.


### The flow

#### Create
The logic of the game UI (javascript) will call an `/session_key/create` endpoint on the TG, which will return the account address corresponding to the SK.
The game UI will create a value transfer transaction from the main account to this address with enough money to prepay for the moves. The user must sign it with their wallet.

The game will call `/session_key/activate/${sk_account}`

After the initialisation, the game will create unsigned move transactions and submit them to the TG.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe worth saying explicitly how that tx part works, I guess it's like /session_key/submit_tx or something? And the payload is similar to eth_sendRawTransaction.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

in my mind it would be a normal transaction, sent via the normal rpc. Only that the signature fields are 0 or something

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah ok fair, yeah if the wallets let you do that then that'd work nicely

The TG will sign these transactions with the active SK and submit them to the network.

#### Reuse

If the user already has a session key, the game can retrieve it with `/session_key/list`. This will return a list of `address, amount`.
Copy link
Collaborator

@BedrockSquirrel BedrockSquirrel Aug 15, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

I've just realised there's a bit of a security issue here. We have an rpc method that returns the user ID, which means if someone makes a webpage with a 'Connect wallet' button then it can:

  • request userID
  • request list of session keys for that user ID
  • submit unsigned transactions to drain their balances

Possible solutions that spring to mind:

  1. Remove query method that returns the user's ID, require all communcation to go via MM RPC without leaking the userID/RPC address (not sure if this is feasible with the initial signing part...)

  2. Restrict the transactions that a session key can make. For example, when you call /session_key/create you could require a contract address be included in the request body and limit that session_key to creating transactions to that address. This would prevent anyone that knows the userID from draining the funds directly.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Tbh I think number 1 needs to be seriously considered because even without session keys this means that whenever you connect your wallet to an app you risk them snooping through your 'private' tx data.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Another option is that userIDs could be sessioned. If you make a request to a user ID from a different IP or after a long period of time then you're forced to re-authenticate with your EOA signature...

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Tbh I think number 1 needs to be seriously considered because even without session keys this means that whenever you connect your wallet to an app you risk them snooping through your 'private' tx data.

yeah, totally. I was thinking the same

The game has the option to top up the value, or activate it.

#### Ending the game

The game can create transactions to move the values accumulated by the Sk to the main account, and submit them to the TG.

When that is finished: `/session_key/deactivate`, which returns `address, amount`.

#### Deleting a SK

SKs need to be stored on the TG to allow the user to query in the future

#### Exporting the SKs

`/session_key/export/${sk_account}` - returns the private key


### Implementation on the Ten Gateway

1. Store SKs in the database and manage them via the `session_key` endpoints
2. Sign the SK account with the vk of the user
3. Mark a session active per user and sign transactions with the SK
4. When the user queries data, also include the SKs as candidates. Todo: think about when the data needs concatenation