Closed macalinao closed 2 years ago
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.
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!
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)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.
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.
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:
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:
alg
is set to ETH.address
field must be included in the payload. This address is cross-referenced with the checksummed address retrieved fromecrecover
to verify the authenticity of the message.web3.sign(payload)
wherepayload
is defined as per the JWT standard.Authentication to an HTTP server can be done by specifying the header:
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.