---
# System prepended metadata

title: Sign-In with Ethereum Proposal

---

# Sign-In with Ethereum Proposal

- Introduction
- Goals & Deliverables
    - standardized way to authenticate instead of signing
    - google sign in equivalent
        - Basic authentication
        - Sessions/duration
    - extendable to include blockchain data
    - Web2 to use it
    - Compatibility with OAuth standards
    - Non reliance on servers
        - potentially restricted to implicit flow or PKCE for auth code flow
- Project Approach and Schedule
    - Stakeholders
    - Setting up comittee for review/feedback
    - Who we will be surveying
    - Specfication creation
    - Implementation
        - Requires multiple
    - Pilots and example usage
    - Hand-off and future maintenance
- Draft Solution
    - Current practices
        - Existing Approaches (personal sign)
        - OAuth/2
    - Summary of core changes/extension from OAuth specification
    - Roles
        - User
        - Application
        - Registry
        - ...
    - Implicit flow
        - pros/cons
    - Auth code flow with PKCE
        - pros/cons
    - Scope
        - name (ENS name)
    - Verifying authority
        - unlike normal OAuth, verifying authority is the user, not a centralised entity
        - smart contract wallet signing key lookup vs EOA
        - backend infura for verifying
    - Access token format
        - supported curves / algos
        - sample JWT
            - note: additional fields should be OAuth compliant
    - Security considerations
        - JWT must sign over redirect_uri in browser
        - token generation page must be hosted by wallet / decentralised service
        - cross-site request forgery
    - Extensions
        - more scopes
        - attestation 
        - integration into web2 OAuth aggregation platforms
        - refresh tokens


- Team and Budget
- Closing Remarks
























## Things we should in include

#### OAuth Specific
- PKCE
- Implicit Flow / Auth Code flow
- Attestation/Permission granting moving forward (scope)
- they may also want to implement this to be compabilible with the OAuth spec itself
    - for example if its included in a JWT algo signing, or JWK
    - or if perhaps we reference the OAuth spec and extend it to work

#### Goals of implementation
- Basic authentication
- Sessions/duration
- Web2 to use it potentially

#### Others
- SCW compatibility (how?)
- ENS usage moving forward
- Platforms (Native/Web)
- Examples and next steps forwards
- Redirect url
- Error responses
- Future work: refresh tokens
- Future work: verifiable credentials
- Future work: extensions on grants / permissions

#### Existing solutions

## Introduction

The Ethereum Foundation (EF) and True Names LTD (ENS) would like to create a Sign-In with Ethereum specification, a package using OAuth for easy implementation by web2 services, and a Javascript library for the user-facing part of sign-in.

Reach out to login providers
What do we do if it a SCW?
One of the goals is defo reaching it out to web2?
Attestation moving forward?

## Existing Approaches
- https://eauth.pelith.com/login

