ERC-1341: Ethereum Web Tokens

[macalinao]

eip: 1341
title: Ethereum Web Tokens
author: Ian Macalinao <ian@abacusprotocol.com>, Pradyuman Vig <pradyuman@abacusprotocol.com>
discussions-to: this issue
status: WIP
type: Standards Track
category: ERC
created: 2018-08-20

Simple Summary

JWTs signed using Ethereum addresses.

Abstract

Ethereum web tokens (EWTs) are a subset of JSON web tokens that are signed using Web3. They provide all of the benefits of JWTs while also using Ethereum's cryptography system.

Motivation

There are many use cases out there for authentication, including:

• Standardizing authorization to permissioned ERC721 metadata
• Restricting API access to certain Ethereum addresses
• Proving ownership of an Ethereum address
• Basically anything auth related!

By creating an authentication specification that plays well with Ethereum, we can standardize the way people authenticate with off-chain systems using their Ethereum address.

Specification

EWTs are just JWTs with a few additional constraints:

• The alg is set to ETH.
• An address field must be included in the payload. This address is cross-referenced with the checksummed address retrieved from ecrecover to verify the authenticity of the message.
• The signed payload is the base64url encoding of web3.sign(payload) where payload is defined as per the JWT standard.

Authentication to an HTTP server can be done by specifying the header:

Authorization: Bearer <ewt>

Rationale

The EWT standard is intentionally simple to make it easy to migrate from or integrate with existing JWT-based systems and libraries.

The JWT standard is already well adopted, so it makes sense to use it as a starting point. It contains features such as expiry, issuer name, etc. that don't make sense to reinvent for Ethereum.

The traditional JWT algorithms do not use Web3 to sign messages, meaning that there is a back-and-forth needed to actually generate a JWT showing that you own your address. EWTs are different, and its auth is akin to the way the Github API does its auth except it uses Ethereum's system instead.

Implementation

JS implementation is available here: https://github.com/abacusprotocol/eth-web-token

Copyright

Copyright and related rights waived via CC0.

[MicahZoltu]

Is there a reason to not just use straight JWT? I would like to see some arguments included in this EIP on how JWT fails to solve the problem at hand and why we need a new standard.

[macalinao]

Hey @MicahZoltu ! EWTs are a subset of JWTs, meaning that they are fully compatible with the existing standard. I have not reinvented JWT, and I stated in the EIP that we should build on top of the existing standard.

The traditional JWT algorithms do not use Web3 to sign messages, meaning that there is a back-and-forth needed to actually generate a JWT showing that you own your address. What I propose is akin to the way the Github API does its auth except it uses Ethereum's system instead.

I'll update the EIP to clarify some of these points, but I have not stated that JWT fails to solve the problem at hand. Thanks again for your comment!

[rudolfix]

Hey, we were researching similar thing and we finally settled for JWT generated via challenge-response to the backend (here is concept code, pretty old now https://github.com/Neufund/signature-authentication-server/).
The reason is that if you really want to prove that someone controls given wallet (key pair) you must request to sign an unique challenge.
In proposed standard JWT is self issued and as far as I understand the intention is to be used against many different backends. You must trust those backend that your universal, re-usable (?) JWT is not leaked and then used to authenticate you by attacker.
My worry is that we may promote an unsafe pattern. The least I would do is make a few standard JWT fields mandatory

• iss is always user address (we are self-issuing)
• sub is user address or alternatively user acting identity (like in ERC725)
• exp and iat must be set and there should be strict requirements on them. (like max TTL of JWT is one hour)

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.