1wallet app library about one-wallet

[hypnagonia]

when using redirect an application loses all non-persistent state

we can extend redirect approach providing developers conventional library with async methods

const address = await wallet.auth()

using cross tab communication
https://github.com/pubkey/broadcast-channel

library on page A opens wallet's redirect url on new tab B
on B wallet eventually redirects back to callback url
library listens to location change and once it is callback url, emits data to other tabs (A) and self close (B)
on page A library receives the crosstab event and returns the response to the app

so we can implement conventional wallet connect interfaces like
https://github.com/WalletConnect/walletconnect-monorepo

[givp]

@polymorpher for the redirect option, I recommend borrowing concepts from OAuth2 protocol by making the handshake a multi-step process. Like OAuth, the redirect should obtain a temporary request token and then the client can use that to exchange with an access token to complete the transaction. It is obviously not identical but I see many "man in the middle" security holes if the redirect flow is not implemented correctly.

[polymorpher]

@polymorpher for the redirect option, I recommend borrowing concepts from OAuth2 protocol by making the handshake a multi-step process. Like OAuth, the redirect should obtain a temporary request token and then the client can use that to exchange with an access token to complete the transaction. It is obviously not identical but I see many "man in the middle" security holes if the redirect flow is not implemented correctly.

I thought about using OAuth2. The problems are the following. It would require the application developer to register the app with a central authority which manages and generates secrets for each application. The app would also be forced to bind with a particular client instead of the wallet, since the confidential OAuth token cannot be stored on the wallet - it has to be stored at the wallet client and has a short-lifespan.

A major difference between OAuth flow and the use cases here is that neither the app nor the wallet would be expected to do anything offline - the user is involved in every step, and no authorization token is issued to allow either the wallet or the app to do anything without the user's involvement. I think Redirect should be secure against attacks for the following reasons:

1. The first redirect from the app to the wallet is secured by HTTPS. If the app redirects to a malicious URL, the malicious URL would not be able to perform use case (2)(4)(5)(6) because it cannot access the storage and state of the wallet which are associated with 1wallet.crazy.one.
   1. For use case (1), if the malicious URL creates a tampered wallet, the client library can detect the wallet's code hash is incorrect by retrieving and hashing the code using the returned wallet address. We cannot prevent a malicious URL from creating a untampered wallet, but neither can OAuth, and this scenario would be harmless.
2. At the wallet, the user can inspect the request and verify the requested parameters. This and step 1 ensure the request is not tampered with.
3. If the request generates a signature, the signature committed, produced, and stored on-chain will be only valid for the request. This applies to use case (2)(5)(6). The signature can also be validated by the app by performing read-only operation on-chain via the library.
4. If the request performs some action and produces a transaction id (use case (4)) or an address (use case (1)), the transaction id can be validated similarly to step 3.
5. Use case (3) does not require Redirect.

[givp]

Would be great to create a data flow diagram for the redirect solution.

[stephen-tse]

let's focus first on just the use case 6 (authorize a request). a tip jar demo as a single-page web app will be useful for our hackathon – even as dao peer bonus like yearn's https://coordinape.com. a helpful feature: no reauthorize for 30 mins for total 100 ONE tokens.

for ux or security flow, google "ethereum login" or "ethereum authentication" or "ethereum iframe". https://github.com/burner-wallet/burner-wallet-2 is a good reference, too.

[polymorpher]

Coordinape restricts access but the article linked on the site is informative: https://medium.com/iearn/decentralized-payroll-management-for-daos-b2252160c543

Yes, we can start with a quick tip jar demo based on (5) request authorization and (4) transfer

[Dewansahil]

@polymorpher have you checked out Atheneum app connection libraries? https://docs.authereum.com/integration

[polymorpher]

Note: work is underway in various PRs. Also see documentation in https://github.com/polymorpher/one-wallet/wiki/App-Integration

[saulgiordani]

This is a great project, I'm starting to develop an application based on Harmony and I'd really love to be able to integrate such a feature. Will follow this thread with lot of curiosity. Good luck!