Do we need an AuthServer?

[zemse]

I've been looking at the readme file, and the problem which this project aims to solve is very important. Even I've been working on this, but not getting much time to work on this/ would like to contribute.

From the Readme, I see that purpose of AuthServer is to verify signatures. Here, phone and computer are peers and they have to depend on the AuthServer as a middleman for functioning. I think a server is not required to verify signatures since it's pure Elliptic Curve Cryptography which means the phone and computer can do themselves. A computer browser can generate a random number, this number should be relayed to the phone using something like WebRTC for it so sign it using the private key and can relay the number with the signature back to the computer browser UI and a continuous WebRTC connection can be established between the browser and the phone. Further, signature requests for every action from the dApp can be sent to the phone for signing as long as the connection is active.

Currently, there is a service called WalletConnect. My concerns are that the connection is through a centralized server. It means if their server shuts down for a few minutes, users won't be able to use their phone to sign transactions on a dApp running on their computer.

It'd be really great if we can establish a local connection using something like WebRTC, in case the user's computer and phone are on the same WiFi network and only use a centralized server if both devices are not on the same network. P2P communication between the computer and phone can remove the dependency of an authentication server.

[vikramIde]

@zemse

Thanks for the Idea, We are still working on our white-paper, Where we will finalize the approach.

Our first approach was to offcourse use WalletConnect as its accepted widely across many dAPPS.

But we also like your idea would you be interested in contributing to our white-paper?

[zemse]

Hi @vikramIde,

Sure I'd like to contribute as much as I can, to make something like this working and get it implemented. Do tell me how we proceed.

[Vishwas1]

Hey @zemse, Peer to peer signature verification could be problem from the business point of view. It is not just the verification which is done by the AuthServer (which could be replaced with full fledged smart contract if single point for failure is your concern) but also the whole identity infrastructure is build on top of it. Let 's connect to discuss more. How about linkedin?

[zemse]

The purpose of the signer which I am talking about is only to relay unsigned transactions to phone app for user to sign it using private key and relay the signed transaction back to the browser in the laptop, and you already know this is what WalletConnect does, but through servers. If I am here, my phone is here, my laptop is here, why can't my phone and laptop talk to each other instead of bringing a server or smart contract between them? Right now there are less dApp users, they can grow soon and requests to the WalletConnect servers will increase and eventually more servers will be required. If P2P is possible then the traffic on the servers can be reduced and such server resources can be utilized for other useful things.

Yea, let's also get connected on LinkedIn. From what I understand, if business finds the information transfer between laptop and phone useful (which would anyways find it's way to blockchain but I assume there is more to it in case of Hypersign as you have mentioned identity infrastructure and also I do not know these details since I couldn't manage time to dive in the whitepaper yet) then definitely AuthServer could be the way for Hypersign. Can you pls confirm if this is the case? If it is then I feel only way to take the P2P idea forward might be to have a separate open-sourced project focused only on the transaction relaying part using WebRTC.

[zemse]

Looks like we're already connected on LinkedIn :)