Add EIP-5388: Token-Gated HTTP Endpoints #5388

TimDaub · 2022-08-01T14:35:24Z

For now, I'm submitting this proposal as a draft. It essentially generalizes token-gating as implemented by e.g. Ocean Protocol.

Summary of this PR:

https://twitter.com/timdaub/status/1554116824006103040

What I could need help with:

Not sure what exactly I should write in the "Rationale" section
Is it fine to ignore the backward compatibility section for now? It seems this proposal doesn't have to be backward compatible
What would be the security implications of such a standard?
Have I outlined the EIP-712 section well? My confidence in working with EIP-712 is low, so I'd appreciate feedback, safety reviews, and help

TODOs:

X-ABI-ENCODED-INPUT should be prefixed with `EIP-XXXX´ too
Create Magician's thread
When requesting the endpoint with authorization, we should probably mandate that the user submits a transaction ID with the executed suggestion too
A server must send a chain-ID along with the suggested encoded abi and a contract address
Consider removing the X- prefix from headers
Consider giving advice about "payable" value in case ETH is expected

EIPS/eip-XXXX.md

eth-bot · 2022-08-01T14:36:12Z

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

(fail) eip-5388.md

classification
`newEIPFile`

File with name EIPS/eip-5388.md is new and new files must be reviewed
This PR requires review from one of [@lightclient, @axic, @SamWilsn, @Pandapip1]

EIPS/eip-XXXX.md

github-actions · 2022-08-01T14:37:12Z

The commit a073021 (as a parent of 2399a6f) contains errors. Please inspect the Run Summary for details.

EIPS/eip-XXXX.md

github-actions · 2022-08-01T14:40:52Z

The commit 361a52e (as a parent of 14d0e5c) contains errors. Please inspect the Run Summary for details.

Pandapip1

First pass

Pandapip1 · 2022-08-01T14:37:04Z

EIPS/eip-XXXX.md

+
+## Abstract
+
+This standard introduces composable RESTful HTTPS and Solidity interfaces that e.g. enable paying to access HTTPS endpoints using [EIP-20](./eip-20.md) tokens.


Suggested change

This standard introduces composable RESTful HTTPS and Solidity interfaces that e.g. enable paying to access HTTPS endpoints using [EIP-20](./eip-20.md) tokens.

This EIP introduces composable RESTful HTTP and Solidity interfaces that e.g. enable paying to access HTTP endpoints using [EIP-20](./eip-20.md) tokens.

Nit

Pandapip1 · 2022-08-01T14:39:36Z

EIPS/eip-XXXX.md

+
+## Motivation
+
+According to RFC 7231, HTTPS status `402 Payment Required` is reserved for future use. But the future is now as Ethereum enables users to verify their identity with a server using public key infrastructure.


Something about "the future is now" rubs me the wrong way...

Yeah it's a bit too aggressive for a standard document. I'll make it more neutral.

EIPS/eip-XXXX.md

Pandapip1 · 2022-08-01T14:40:27Z

EIPS/eip-XXXX.md

+"{\"constant\":false,\"inputs\":[{\"name\":\"_from\",\"type\":\"address\"},{\"name\":\"_to\",\"type\":\"address\"},{\"name\":\"_value\",\"type\":\"uint256\"}],\"name\":\"transferFrom\",\"outputs\":[{\"name\":\"success\",\"type\":\"bool\"}],\"type\":\"function\"}"
+```
+
+### Authorization via EIP-712 Signature


Suggested change

### Authorization via EIP-712 Signature

### Authorization via [EIP-712](./eip-712.md) Signature

EIPS/eip-XXXX.md

github-actions · 2022-08-01T14:47:13Z

The commit e89bf56 (as a parent of 9b77df8) contains errors. Please inspect the Run Summary for details.

EIPS/eip-5388.md

Pandapip1 · 2022-08-01T19:04:08Z

EIPS/eip-5388.md

+
+## Rationale
+
+There is no rationale related this standard.


Suggested change

There is no rationale related this standard.

TBD

EIPS/eip-5388.md

julien51 · 2022-08-04T10:38:47Z

EIPS/eip-5388.md

+Upon the user's initial request, a HTTPS server implementing token-gating via EIP-5388 responds with a `402 Payment Required` status code:
+
+- Its body must include a valid JSON string that complies with the Solidity Contract ABI Specification for calling contracts.
+- It must include a custom header `X-EIP-5388-CONTRACT-ADDRESS` that suggests the contract's address a call must be directed to.


The use of the X- prefix, while very common is actually considered useless (if not harmful..) so I think it would be ok to skip it in favor EIP-5388.

I think it is important to make sure this address is compatible beyond Ethereum mainnet by adding the chain id.

The use of the X- prefix, while very common is actually considered useless (if not harmful..) so I think it would be ok to skip it in favor EIP-5388.

Can u please add a reference that explains why the X- prefix is harmful/useless?

I think it is important to make sure this address is compatible beyond Ethereum mainnet by adding the chain id.

Makes sense, will add it.

Can u please add a reference that explains why the X- prefix is harmful/useless?

X- headers are for non-standardized headers. So if I have an Application A that needs to return a custom header (for some reason), I should prefix it with X-.

This is a standard. You can (and should) drop the X-.

Can u please add a reference that explains why the X- prefix is harmful/useless?

There is a good SO thread there and my good friend Peter wrote an RFC a while back https://www.rfc-editor.org/rfc/rfc6648

https://stackoverflow.com/questions/3561381/custom-http-headers-naming-conventions

Co-authored-by: Pandapip1 <[email protected]>

xinbenlv · 2022-09-24T22:19:56Z

EIPS/eip-5388.md

+---
+eip: 5388
+title: Token-Gated HTTP Endpoints
+description: Composable RESTful and Solidity interface to implement token-gated HTTP endpoints using data tokens.


I think HTTP and RESTful can be decoupled. If this EIP mandates RESTful API, the title shall reflect it. If it only mandates HTTP, then I think we can drop the RESTful in the description and just keep it about HTTP endpoint?

Agreed, I am not sure REST is required/useful?

Cool!

I kind of like to also have a RESTFul standard, but it can be one level above HTTP, hence that it self could have an separate EIP.

xinbenlv · 2022-09-24T22:21:09Z

EIPS/eip-5388.md

+Upon the user's initial request, an HTTP server implementing token-gating via this EIP responds with a `402 Payment Required` status code:
+
+- Its body must include a valid JSON string that complies with the Solidity Contract ABI Specification for calling contracts.
+- It must include a custom header `X-EIP-5388-CONTRACT-ADDRESS` that suggests the contract's address a call must be directed to.


Suggested change

- It must include a custom header `X-EIP-5388-CONTRACT-ADDRESS` that suggests the contract's address a call must be directed to.

- It **MUST** include a custom header `X-EIP-5388-CONTRACT-ADDRESS` that suggests the contract's address a call must be directed to.

xinbenlv · 2022-09-24T22:21:22Z

EIPS/eip-5388.md

+
+- Its body must include a valid JSON string that complies with the Solidity Contract ABI Specification for calling contracts.
+- It must include a custom header `X-EIP-5388-CONTRACT-ADDRESS` that suggests the contract's address a call must be directed to.
+- It must include a custom header `X-EIP-5388-ABI-ENCODED-INPUT` that suggests the call signature the user must invoke at `X-EIP-5388-CONTRACT-ADDRESS` to gain access to the endpoint.


Suggested change

- It must include a custom header `X-EIP-5388-ABI-ENCODED-INPUT` that suggests the call signature the user must invoke at `X-EIP-5388-CONTRACT-ADDRESS` to gain access to the endpoint.

- It **MUST** include a custom header `X-EIP-5388-ABI-ENCODED-INPUT` that suggests the call signature the user must invoke at `X-EIP-5388-CONTRACT-ADDRESS` to gain access to the endpoint.

xinbenlv · 2022-09-24T22:25:02Z

EIPS/eip-5388.md

+
+- Its body must include a valid JSON string that complies with the Solidity Contract ABI Specification for calling contracts.
+- It must include a custom header `X-EIP-5388-CONTRACT-ADDRESS` that suggests the contract's address a call must be directed to.
+- It must include a custom header `X-EIP-5388-ABI-ENCODED-INPUT` that suggests the call signature the user must invoke at `X-EIP-5388-CONTRACT-ADDRESS` to gain access to the endpoint.


I feel the spec also lacks a part in solidity interface for what smart contract it will be to respond to a end point request

not sure I understand what you mean, would you mind elaborating?

I think what @xinbenlv is asking is probably which are these contracts that these endpoints might be dependent on, as suggested in his changes. Is that it?

Co-authored-by: Pandapip1 <[email protected]>

Rachi26 · 2022-09-25T07:51:43Z

شكرا

julien51 · 2022-10-19T19:30:33Z

EIPS/eip-5388.md

+
+## Abstract
+
+This standard introduces composable RESTful HTTP and Solidity interfaces that enable paying to access HTTP endpoints using [EIP-20](./eip-20.md) tokens.


I am not sure it is about REST?
Also, why require ERC20... I think it could be more flexible...

This standard introduces composable HTTP and Solidity interfaces that enable restricting to access HTTP endpoints using smart contracs.

julien51

I think the general idea is a very good one, but this needs more generalization!

Ideally the HTTP server would return a way for the user agent (browser) to know what it will perform as verification in order to check if the user(identified via the signature) should be grated access, but also offer (optionally) a way for the user agent to actually trigger a transaction that would satisfy the conditional access.

So you'd have a flow like this:

User agent queries server
Server responds: I need to know who you are (please sign a message) and once I know I will run this check on the chain. If you want this check to be "positive" here is what you need to do "optionally".
UA can then request user to sign, and once they have can check if indeed the user satisfies the required condition to get access.
If so, UA (re)sends request with the appropriate header to identify user
If not, UA prompts users to execute the transaction that would satisfy condition (a smart UA could even simulate the tx to verify that indeed it satisfies the condition).
Once Tx confirmed, the UA could (re)send request to the server

I think it would be useful to think of making the user identification itself flexible, because we may want to eventually support privacy preserving approaches where the UA does not submit a signature but a proof (zk?) that they satisfy the condition prompted by the server.

github-actions · 2022-11-26T00:17:40Z

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR 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 · 2022-12-12T00:19:06Z

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR 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 · 2023-01-24T00:18:30Z

This pull request 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.

Initial draft

a073021

github-actions bot added the type: ERC label Aug 1, 2022

Pandapip1 reviewed Aug 1, 2022

View reviewed changes