Authentication for storage queries

[brenzi]

Most substrate chains are entirely transparent and everyone has read access to all the storage. Privacy focused chains, like the Integritee privacy sidechains, on the other hand, only authorize queries based on authentication. (Only the owner of an account can query their own balance) Apart from that requirement, all else could work like normal substrate rpc.

For easy integration and compatibility with wallets, we suggest to specify authentication for storage queries here.

The node may also define "view keys" (similar to how the proxy pallet works), so we can't generally assume that the authorization is restricted to the signer's own account. Also, some storage may not require authentication, like total supply of tokens or the block number)

It is not yet clear to me, what the best procedure would be for this spec, which are easy to implement for wallets. looking forward to ideas here.

[tomaka]

How is this currently done? With custom JSON-RPC functions?

And what is this authentication data? Some kind of signature made with the private key of the account?

[brenzi]

Currently we have a custom rpc which is incompatible with existing generic wallets/frontends.

We do require a signature by the private key of the account which shall be authorized for this query. The signed payload being the query.

[tomaka]

The signed payload being the query.

For what it's worth, if this signed query gets intercepted, anyone can replay it and be granted access. Same for the owner of the JSON-RPC server who can just intercept the result.

[brenzi]

The signed payload being the query.

For what it's worth, if this signed query gets intercepted, anyone can replay it and be granted access. Same for the owner of the JSON-RPC server who can just intercept the result.

That is a standard problem and should have a standard solution. We would require a TLS connection.

The most straightforward standardized way might be to use JWT

[tomaka]

The reason why I raised this point is that this seems incompatible with public JSON-RPC server. Or did you imagine limiting the JSON-RPC servers to specific trusted entities?

And when it comes to light clients, they typically don't have access to Intel SGX or whatever you use.

[brenzi]

I need to clarify: We don't suggest to enforce usage of JWT for public json-rpc interfaces. We just suggest to standardize how authentication is done if it is needed. Our use case are sidechains where the chain state is private and account holders need to authenticate in order to query state which they are authorized to see (like own balance) In our case, a sidechain is validated by TEEs and some of these TEEs will expose a json-rpc API which requires authentication. It would be nice if this authentication was standardized and supported by generic wallets such that you could connect i.e. Nova Wallet to our Sidechains as if it was any kind of substrate chain - with the difference that the state is private and queries must be authorized

light clients are out of scope here. We would not require anyone else to use JWT or use TEEs. But if someone else builds any kind of chain with private state, the standard would support interoperability