diff --git a/docs/user-flow.mdx b/docs/user-flow.mdx
index 8a3d02df2..5dc148b85 100644
--- a/docs/user-flow.mdx
+++ b/docs/user-flow.mdx
@@ -27,7 +27,7 @@ flow.**
:::info
-In one our Click Flow, we add a `nonce` value to the social login share to keep the threshold 2/2. while it feels like 1/1. This is done to ensure
+In our One Click Flow, we add a `nonce` value to the social login share to keep the threshold 2/2. while it feels like 1/1. This is done to ensure
that the application has the flexibility to move to a 2/n MFA flow in the future if they want to. As the application triggers the creation of MFA
Factors the nonce is automatically deleted.
@@ -55,15 +55,15 @@ With both Core Kit and Plug and Play SDKs, you have the choice to use multiple t
Play, we expose various logins out of the box. For Core Kit SDKs, the developers can determine which flow suits them the most, with total freedom of
managing key storage and access. For Plug and Play, we have some predefined configurations that can be used.
-| MFA Type | Custodiality of MFA | Ease of Access | Setup Custodiality | Availability in Plug and Play SDKs |
-| ----------------------------- | --------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- |
-| **Recovery Mnemonic Phrase ** | Self Custodial to User | Difficult | Fully Non-Custodial | Yes |
-| **Email Backup Share** | Potentially Custodial to Email Provider | Medium | Non-Custodial
Semi-Custodial _(if same email as 1st factor social login)_ | Yes, SMTP server for email can be customized for Enterprise Customers. |
-| **Backup Password** | Semi Custodial to the Encrypted Metadata Server | Medium | Non-Custodial | Yes |
-| **Secondary Social Login** | Semi Custodial to Social Provider, using Distrubuted Web3Auth Network | Easy | Non-Custodial
Semi-Custodial _(if same social login provider for 1st factor)_ | Yes, however, custom authentication cannot be used for second factor |
-| **SMS Passwordless** | Semi Custodial to SMS Service using Distrubuted Web3Auth Network | Easy | Non-Custodial | Yes, however, custom authentication cannot be used for second factor |
-| **Email Passwordless** | Semi Custodial to Email Provider using Distrubuted Web3Auth Network | Easy | Non-Custodial
Semi-Custodial _(if same email as 1st factor social login)_ | Yes, however, custom authentication cannot be used for second factor |
-| **Passkeys** | Semi Custodial using Distrubuted Web3Auth Network | Easy | Non-Custodial | No |
+| MFA Type | Custodiality of MFA | Ease of Access | Setup Custodiality | Availability in Plug and Play SDKs |
+| ----------------------------- | --------------------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
+| **Recovery Mnemonic Phrase ** | Self Custodial to User | Difficult | Fully Non-Custodial | Yes |
+| **Email Backup Share** | Potentially Custodial to Email Provider | Medium | Non-Custodial
Semi-Custodial _(if same email as first factor social login)_ | Yes, SMTP server for email can be customized for Enterprise Customers. |
+| **Backup Password** | Semi Custodial to the Encrypted Metadata Server | Medium | Non-Custodial | Yes |
+| **Secondary Social Login** | Semi Custodial to Social Provider, using Distributed Web3Auth Network | Easy | Non-Custodial
Semi-Custodial _(if same social login provider for first factor)_ | Yes, however, custom authentication cannot be used for the second factor |
+| **SMS Passwordless** | Semi Custodial to SMS Service using Distributed Web3Auth Network | Easy | Non-Custodial | Yes, however, custom authentication cannot be used for the second factor |
+| **Email Passwordless** | Semi Custodial to Email Provider using Distributed Web3Auth Network | Easy | Non-Custodial
Semi-Custodial _(if same email as first factor social login)_ | Yes, however, custom authentication cannot be used for the second factor |
+| **Passkeys** | Semi Custodial using Distributed Web3Auth Network | Easy | Non-Custodial | No |
### Setting up the Threshold for MFA
@@ -74,12 +74,12 @@ This gives the user a flow that they're used to alongside ease of access on thei
That being said, the threshold can be set to any number as per the security requirements of the integrating application. However, this can be done
only using the Core Kit SDKs. The Plug and Play SDKs come with a default threshold of 2/n.
-| Parameter | restricting to 2/2 shares | allowing ≥ 2/3 shares |
-| ------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Non-Custodiality:** Ownership/access to a user 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. Conversely the likelihood of a user’s key being lost, due to a loss of factors. | 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. |
+| Parameter | restricting to 2/2 shares | allowing ≥ 2/3 shares |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Non-Custodiality:** Ownership/access to a user key and/or Ability to grief? | “Semi-custodial” - Never has access but nodes/ network always can grieve 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. Conversely the likelihood of a user’s key being lost, due to a loss of factors. | In a 2/2 setup, the nodes become even more important. If nodes go down/lose factor due to issues users lose their keys. 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 user's 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 and reshare the key out (without extra validation/restriction) it's as good as v1 technically as a hacker can always reshare the user keys. |
### Ideal time to trigger MFA according to the user flow