shanejonas
commented
4 years ago Just some initial thoughts
Option B seems like it would work similar to some of the early discussions with @BelfordZ on populating the servers[] array with peers that also serve up the same JSON-RPC api.
Option C reminds me of how geth boots and connects with devp2p:
"on first joining the network each node generates an ECDSA key pair "
and maybe both of those play into the login stuff:
https://ethereum-magicians.org/t/web3-login-permissions/3583
Currently, the jade service runner is open for all request. We need a system that supports restricting access to RPC services on the users behalf.
The requirements from both sides are as follows.
It seems like the most straight forward way to achieve the above, is to create domain/ request origin based restrictions on access. This requires 0 changes to expectations that developers have about accessing a service. The most problematic issue here is the eventual issue of non domain originating request, which might lend itself to a separate method of authentication.
To have complete coverage of all cases, and support for peering might require, more work. It might make sense, in order to support p2p use cases that we use a capabilities security model , where a dApp might register with a users service runner, and be able to delegate that other service runners have the capability to receive requests from a 3rd party user.
The use case extends from the following.
User A is using a dApp that creates a client called SimpleMath, that communicates over a p2p transport. The client searches the service runner network for available SimpleMath service peers, retrieves a list of peers and makes request to the list of available peers. In order to support making request to these 3rd party SimpleMath service peers, you would be required to as member of the p2p network, add this user, user A to a whitelist as a peer service provider.
The options if you don't as a peer just open the service to all request, is to A. whitelist all incoming request ip individually B. open the service to all request / or only certain services endpoints to all request C. use a capabilities scheme and request the user prove they have the request capabilities.
In option C, loosely the dApp would give the user the capability to make a request, and with the peering request would provide the peers with proof of the capability to make a request with regards to the dApp . I.e. the people/machines that are serving as peers are then accepting request to a service originating from the service, but not a specific origin domain. I imagine a scheme that is probably in line with OCAP-LD. and takes some inspiration from web3 Login EIP.
Short Term vs Long Term. I feel as though its very unclear that when we get to peering, that people will not simply want to restrict bandwidth, and blacklist services entirely from services that might expose them to leaking personal data or that they don't want to make through the network.
The way forward seems. Implement simple origin domain whitelisting/blacklisting that can be toggled per service, and see slowly how use cases drive future development in this area of restricted RPC calls.