EXP-0002: App Sessions

Table of Contents

• Background
• Overview
• Example
  • Initialize an Account
  • Executing With & Without Sessions
• Conclusion

Background

Imagine you are using an app. You open the app in your web browser or download it from your device’s App Store, log in or sign up with a email/password, OAuth, Face ID, or some other common method, and you are good to go.

Once you go through the authentication process, you can perform several actions in the app. You can write reviews, add products to your cart, manage payment methods, and check out. All these actions use your current session info instead of making you re-authenticate every time. This is the experience most people in the world are familiar with when they are using apps.

Now, imagine you are using an Ethereum-enabled app. In most cases, you need to show up with an app or extension installed to get started. Likely there is also additional message signing, prompts to approve and confirm, and more sprinkled in throughout the experience.

What if there was a better way? Try out the inline swap app below (with “Use Session” toggled on and off) and read on to learn more about how it works.

Overview

In this experiment, we explore sessions for WebAuthn-based accounts and how they enable developers to build apps that feel comparable or better than traditional authentication options (email/password, OAuth, magic links, etc).

To accomplish this, we build on EXP-0001 and introduce sessions via authorized non-extractable Web Crypto keys.

Example

With EXP-0001, we demonstrated Account Delegation with EIP-7702 to create an Externally-owned Account (EOA) that is controlled by a WebAuthn key (e.g. Passkey) and verified using the RIP-7212 P256 Precompile.

This has many use cases, including sponsored transactions and batched calls, but does not significantly improve user experience as you are still presented with confirmation prompts whenever you perform actions. Confirmation prompts are important for transferring large amounts, suspicious transactions, etc. (think your bank’s fraud filter declining your valid $8k flight from NYC to Melbourne, Australia). For every day actions, like paying friends, subscriptions, or online shopping, they likely introduce too much friction into the experience.

For this example, we will be using and interacting with the Odyssey Testnet. We will also be utilizing the ExperimentDelegation contract for Account (EOA) delegation.

Initialize an Account

Following the same steps as EXP-0001, we initialize an account. You can either click on “Register” to create a new Account, or “Sign In” to sign into an existing one that you created previously.

This time, before generating the account, we use the Web Crypto API to create a non-extractable P256 key account session key. The Web Crypto key is then stored in IndexedDB¹ and authorized along with the WebAuthn P256 key.

What does this step enable? Well, if you’ve been paying attention, you know the answer is: Account Sessions.

(Note: This example uses the Web Crypto API, but you can create sessions using other methods.)

Executing With & Without Sessions

Account-based sessions are an attempt to solve user experience issues with prompt fatigue and reviewing signature requests. Try the two apps below. They are the same, except one has sessions enabled and the other does not.

This is a simple example, but we hope it’s easy to see the potential for sessions to improve the user experience and remove friction. In the “With Session” example, once you sign in, you are free to perform actions without getting prompted for signatures. In the “Without Session” example, this is the opposite and you must sign every time you perform an action.²

Conclusion

This is a demonstration on how to use account-based sessions to improve user experience in Ethereum-enabled apps. It’s a work-in-progress and highly experimental, but we are excited by the potential of fast, secure accounts combined with frictionless user experiences (that also happen to have payments attached).

Some future explorations and improvements to tackle in subsequent experiments (please get in touch if you are interested in any of these things):

• Adding session permissions
• Adding support for cross-app sessions and keys
• Adding support for cross-chain accounts
• Addressing the blind signing problem
• Batching up login and session creation

We are excited to see what you build and welcome contributions to the discussion around account-based sessions.