Title: WalletConnect___Connecting_desktop_Dapps_to_mobile
Category: Web

Author: pedrouid
Date: 2018-06-18T18:00:00.500Z

Hi everyone
If you haven’t heard of WalletConnect it’s an open-source project that enables desktop Dapps to interact with mobile Wallets. Richard presented it on Web3 UXUnconf
The user flow is pretty simple, the user scans a QR code to initiate a session which then allows the Dapp to retrieve the user’s accounts. From there, the user can use the Dapp freely on desktop and once there is any messages or transactions to be signed, they are pushed to your phone as a notification and the user can view and signed them securely.
Video Demo: https://twitter.com/ricburton/status/978509303500984320
This UX removes the requirement to install a browser extension and opens up a whole world of Dapps to all mobile wallets available on iOS and Android. It also provides the ability for the user to manage their assets with one wallet without being tidied to one desktop or having to move their seed phrase from one application to another.
I wanted to open this topic to engage with anyone who wants to contribute to this project and add their inputs to the discussions as we develop new standards or features to this protocol.



GitHub



WalletConnect
Open protocol connecting Wallets to Dapps. WalletConnect has 111 repositories available. Follow their code on GitHub.





Looking forward to hear your opinions and suggestions!

Author: MicahZoltu
Date: 2018-06-19T03:25:57.671Z

How does it compare to Parity’s mobile hardware wallet?

Author: pedrouid
Date: 2018-06-19T14:22:48.457Z

Parity Signer involves a lot more QR code scanning so technically there is not message relaying through any sort of infrastructure
While Parity’s implementation you have to scan QR code both from desktop and mobile with WalletConnect’s implementation you only scan the QR code once and all of the comunications are relayed through a Bridge server. The information is never accessible by the Bridge as the session is initiated between the desktop and the mobile with a QR code that shares a ephemeral key for encrypting all messages
These messages are very simple and do not share any critical data that could expose the wallet but secure it from being tampered with, here is the technical walkthrough of the WalletConnect implementation:
Creating a session:

Desktop pings Bridge to create a session ID
Desktop generates ephemeral shared Key
Desktop shares session ID, bridge URL and shared Key with Mobile using a QR code
Mobile scans the QR code and obtains the session data

*** immediatelly after scanning the QR code ***
Getting Accounts:

Mobile is prompted to initiate the session and share wallet Accounts
Mobile encrypts Accounts with shared Key and sends it to the bridge URL using the session ID
Desktop listens to session ID change and fetches encrypted Accounts
Desktop decrypts Accounts with shared Key

*** at this points the user can freely use the Dapp without worrying about the Mobile wallet until it needs to sign something ***
Transaction Request:

Desktop encrypts a transaction request with shared Key
Desktop sends encrypted transaction request to the Bridge using the session ID
Bridge notifies the mobile Wallet of the transaction request by push notification
Mobile fetches transaction request and decrypts with shared Key
Mobile displays transaction request to the User to be signed
Mobile shares the status of transaction request (reject or approved with tx hash)

PS - I missed one part of the infrastructure for clarity of the explanation. The Mobile wallet shares with the bridge a device ID when initiating the session. This device ID is used to trigger a push notification on the Push server (managed by the Wallet developer)

Author: fubuloubu
Date: 2018-06-19T14:41:01.965Z

pedrouid:


Mobile is prompted to initiate the session and share wallet Accounts
Mobile encrypts Accounts with shared Key and sends it to the bridge URL using the session ID
Desktop listens to session ID change and fetches encrypted Accounts
Desktop decrypts Accounts with shared Key



So, the desktop receives a copy of the encrypted key, therefore it is transporting this encrypted key over a secure pipe? Is the desktop supposed to destroy this key after the session?

Author: pedrouid
Date: 2018-06-19T14:51:06.318Z

There is only shared Key that is being used for encryption between the Desktop and the Mobile.
This key is generated on the Desktop and is shared with the Mobile using the QR code when initiating the session
The session management/lifetime is however a great question.
There are several determining factors in this matter that we have discussed so far:

Should the session lifetime be controlled by the Mobile wallet or fixed by the WalletConnect standard/library?
How long should we allow the Desktop dapp to expose this shared key? Specially regarding browsers local storage which is vulnerable and exposing this shared key could open vulnerabilities for phishing and spam.
2.1 Would a Dapp smart contract registry prevent phishing from having this shared key expose?
2.2 Could a User control the authorization from its Mobile wallet without requiring a session lifetime?
2.3 Should we scan the QR code every time the user initiates the session without persisting the session?

Currently the Bridge is persisting the session ID for 24 hours (totally arbitrary decision) but this session ID is useless if the shared Key discarded by the Desktop (example when refreshing a web page without persisting with local storage)

Author: fubuloubu
Date: 2018-06-19T18:46:56.363Z

pedrouid:

Should the session lifetime be controlled by the Mobile wallet or fixed by the WalletConnect standard/library?


I think a 24 hour window is probably fine, but either client using the bridge should be allowed to close it. This way, you could program something in like proximity via bluetooth or wifi where both clients will actively close the bridge when it leaves the coverage area. A laptop might also close if the screen is shut, or even on demand if the user requests it in the mobile wallet (temporary login on a new device)



 pedrouid:

How long should we allow the Desktop dapp to expose this shared key? Specially regarding browsers local storage which is vulnerable and exposing this shared key could open vulnerabilities for phishing and spam.


Both devices can be vulnerable in a multitude of ways. Mobile apps have better guarantees because they’re sandboxed, I hope eventually key management is handled in a similar way for laptops/desktops.



 pedrouid:

Would a Dapp smart contract registry prevent phishing from having this shared key expose?


That’s one way. Or could just use ENS subdomain for the application’s IP address. No expert here, but @alexvandesande had something along these lines he presented at the UX unconf (although I think identity contracts are a harder sell then application contracts)



 pedrouid:

Could a User control the authorization from its Mobile wallet without requiring a session lifetime?


Close the bridge?



 pedrouid:

Should we scan the QR code every time the user initiates the session without persisting the session?


Define “intiating a session”? If that you mean “log into the device”, then that’s not too bad for UX. If you mean every time you load a webpage, that sounds bad.

Author: pedrouid
Date: 2018-07-16T15:54:49.475Z

Created a new discourse for WalletConnect to get into more detail for all components of the standard
https://discuss.walletconnect.org/