# Web3Auth Integration Questionaire
This document lays out a series of questions that helps identify the design principles and choices that fit the ideal key management architecture for your wallet or application.

Before going through the questions, a general understanding of Web3Auth key management is necessary. Do either head to the [docs](https://web3auth.io/docs/overview/how-web3auth-works) or [full MPC overview](https://hackmd.io/Ge_rpr9GTnGGF2oULTGJrg) to get the general picture.

1. Would we want to use existing social logins (e.g. Google, FB, etc..) , or a passwordless login of our own?

2. What apart from user devices and cloud providers, what factors would users be interested in (e.g Devices, Social Recovery, QR backups, email backups)?

3. Do we want to allow importing of keys, with the trade off of key generation integrity?

4. Is non-custodiality defined as only a user should be able to access the key OR is prevention of denial of service also necessary?

5. Should a user always be able to export their key?

6. Enforicing security policies on all users vs key exportability, which is more important?

7. What technology stack would we need the wallet to be compatible with? Mobile iOS/Swift, Andriod Kotlin? Web? Desktop Native?

Many of these questions address whether your key management architecture should restrict the number of existing shares to 2/2 (threshold of two shares to recover, and only two shares that exists) or 2/>3 (threshold of two shares with 3 or more shares that exists) flow is better for your application. Below we list some of the tangible trade-offs to both flows:

| | Description | restricting to 2/2 shares | allowing ≥ 2/3 shares |
| -------- | -------- | -------- | -------- |
| Non-custodiality | What is the definition of custodiality? Ownership/access to a users key and/or Ability to grief? | “Semi-custodial” Never has access but nodes/network always has the ability to grief in this setup, as they always own one of the only factors. | More fully non-custodial, can’t grief, a user can ALWAYS reconstruct their key pair |
| Redundancy | The ability to ensure that users never lose their key. Conversly the likelyhood of a user’s key being lost. Due to a loss of factors or wtv. | In a 2/2 setup, the nodes become even more important. If nodes go down/lose factor due to issues users lose their key. Users get redundancy on their side by copying the factor/share that they have across their devices | In a ≥ 2/3 setup, users can get redundancy in the same way as 2/2 (by copying the same factors) or by increasing the threshold 2/4, 2/5. |
|Control vs security | Restricted access means greater practical security from the network/cloud provider|when we restrict things to the 2/2 flow, we can be certain that the user cannot transact without the node network. While it acts as a sword towards non-custodial, it can be a strong shield. for example we can not allow a tx that withdraws all the users money from the user (unless they do extra validation with us) | in the 2/3 flow the user always has full access to the key. We can still do the same restrictions, but we don’t have the guarantee that the user won’t transact without us cause they can always reconstruct the key |
|Exportability vs Security| Exporting keys from the system | To have a restricted 2/2 flow is to restrict exportability.Still can be done with extra validation. | Always exportable all the time. This could be a detriment as, if we give the ability to transport reshare the key out (without extra validation/restriction) its as good as v1 technically as a hacker can always reshare the users key. |