From Sign-In with Ethereum to Session Keys

The next frontier of Web3 UX

With MetaMask crossing 10 million monthly active users this past quarter, Web3 is responsible for the most successful adoption event of user-held keys ever. Today, the dominant use case for Web3 keys is the signing of blockchain transactions related to digital assets and smart contracts, but this only scratches the surface of what users can do with their keys. The combination of Sign-In With Ethereum (SIWE) and session keys can help unlock the rest.

To illustrate this, imagine a file storage service where users can originate all actions via signing operations with their in-wallet keys, including reading files, writing files, and updating metadata.

What would that look like with wallets today?

A naive implementation might require a MetaMask signature prompt for every action. This would create a disastrous UX, requiring an interruption to be dealt with by the user for every file load, rename, or drag-and-drop operation, which may amount to hundreds of additional decisions per session.

One solution is autosigning, which allows applications to automatically use the user’s keys for certain actions without the wallet displaying a confirmation prompt. This approach has been considered previously by the WalletConnect protocol and several wallet providers, but it has since been discouraged due to its potential for gross overreach of permissions. There is a high potential for abuse if not implemented carefully.

Other approaches that require the user to input their seed phrases or private keys into the browser window have been categorically deemed by the community to create unacceptable levels of risk. The browser DOM is by far a less secure environment than hardware wallets and browser extensions, readily vulnerable to common cross-site scripting (XSS) attacks and weak content security policies.

Enter Session Keys

With session keys, we propose a new point on the tradeoff curve across security, expressive power, and user convenience. With careful implementation, we believe that they can achieve seamless UX and at least the same level of security as HTTP cookie authentication, a technique used successfully at scale for over 20 years. With session keys, we can adopt standard ways to represent capabilities (sometimes known as entitlements) that are platform agnostic, as opposed to cookies which are typically only readable by the issuing website and have proprietary formats.

The use of session keys involves generating new ephemeral keys for a user’s session, stored in the browser and further downscoped in permissions to allow exactly what the user needs to do and nothing more. Like using JWTs for authentication, they can be stored in sessionStorage, which binds them to the current origin and are automatically erased when the browser is closed.

In our example from earlier, an expiring session key is created for the sole purpose of accessing limited parts of the user-governed storage, such as files under a certain subdirectory, using a restricted set of operations (e.g., read-only), within allowed boundaries of resource consumption (e.g., 1 GB of traffic). With a session key, the user is not interrupted to confirm every operation, and if stolen by an attacker, their privileges are already severely limited, and the session key can be revoked or expired automatically.

To achieve and ultimately exceed the quality of interactions that users are accustomed to within Web2, session keys will emerge as a dominant design pattern that simultaneously enables seamless UX while also replacing cookie-based sessions.

From Sign-In with Ethereum to Session Keys

Session keys can be generated from the user’s local system entropy, then assigned permissions via delegation. They are similar to signing-based access delegation found in modern cloud services, such as shared access signatures used in Azure Storage and signature authentication for Amazon S3.

The main difference is that while cloud services produce pre-signed access for a specific operation against a specific resource, session keys can produce actively-signed access to many operations against many resources, limited to what is specified in a capability.

Capabilities represent the ability to do something, typically with some resource, operating on the principle of least privilege. This advanced security model has been in development for decades, with Keynote as one of the earliest known examples. They work a lot like hall passes in the real world, which are signed by teachers in schools to grant students access to the bathroom or principal’s office during normal class hours. Recalling the example from earlier, the owner of the storage grants expiring and attenuated permissions to the session key.

Completely aligned with the tenets of Zero Trust Architecture, capabilities are making their way back into the limelight, deep within next generation system architectures with formats like DPoPs, macaroons, and biscuits. One important reason they haven't fully taken off for end-users, in particular, is that they often work best with Public Key Infrastructure (PKI) already in place. Fortunately, we believe the hundreds of millions of blockchain accounts are the most successful PKI adoption event ever, allowing us to revisit this model with zeal, starting with Ethereum and eventually any other cryptography-based identifiers through decentralized identifiers.

By working closely with organizations such as Ceramic, Fission, and CASA, we can securely interpret the Sign-In with Ethereum message as a delegation to a session key. This means that a user can Sign-In with Ethereum to the storage application and immediately use their new session key to read and write to a limited part of their storage without further prompts as if they were logged into a service with cookie-based authentication. If the session key is stolen, the damage an attacker can do is limited and it can be further deactivated.

We believe this approach can achieve the right tradeoff between keeping the user’s data secure and creating an excellent UX. With session keys, every user action can be rooted in their keys instead of through an intermediary service.

Examples in the Wild and The Road Ahead

Already, dapps are using session key-like workflows. For example, In order to allow users to engage with the platform in an uninterrupted way, Mirror offers users session keys in the form of their “Signing Keys” which authorizes a key to sign on the user’s behalf to avoid wallet interactions. After signing, the user isn’t prompted again to sign for any action they perform on the platform:

In a similar vein, Snapshot generates a key on the user’s browser, stored on localStorage, and the user signs a message delegating this “alias” key as one that can make approvals on behalf of the user. Snapshot is then able to give users a better experience by not needing to reprompt them every time signing is required for an action.

The use cases that we're most excited about, and are actively building towards include:

• Enriching a user’s Sign-In with Ethereum session by accessing a user’s personal datastore or identity hub.
• Creating exportable social media graphs through the issuance and management of Verifiable Credentials by users.
• Establishing cross-chain accounts via long-lived key delegations.

Some of the current next steps include:

• Discussing the implications around security, UX, and control with the community as it relates to session keys.
• Standardizing how to limit access to resources using SIWE by both clients and services.
• Creating an example of this workflow in the Sign-In with Ethereum documentation.

The combination of session keys and capabilities will enable the user-controlled future in which people and not bloated intermediaries govern digital access and permissions, fulfilling “your keys, your data.”

As we continue our work supporting Sign-In with Ethereum, we especially welcome implementers who already have users relying on similar workflows, authors of related EIPs, and wallet vendors who would like to do more to support user-owned identities to join us.

If you are interested in being involved, please join our Discord server: