Merge branch 'master' into sfa-android/v4.0.1

Author: AyushBherwani1998

docs/auth-provider-setup/aggregate-verifier.mdx

@@ -38,25 +38,30 @@ combined. The following table shows all possible combinations of login providers
 
 :::
 
-| First Sub-Verifier | Google | Facebook | Twitch | Discord | Auth0 | Email Passwordless | SMS Passwordless |
-| :----------------- | :----: | :------: | :----: | :-----: | :---: | :----------------: | :--------------: |
-| **Google**         |   ✅   |    ❌    |   ❌   |   ❌    |  ✅   |         ✅         |        ❌        |
-| **Facebook**       |   ❌   |    ❌    |   ❌   |   ❌    |  ✅   |         ❌         |        ❌        |
-| **Twitch**         |   ❌   |    ❌    |   ✅   |   ❌    |  ❌   |         ❌         |        ❌        |
-| **Discord**        |   ❌   |    ❌    |   ❌   |   ✅    |  ❌   |         ❌         |        ❌        |
-| **Email P'less**   |   ✅   |    ❌    |   ❌   |   ❌    |  ✅   |         ✅         |        ❌        |
-| **SMS P'less**     |   ❌   |    ❌    |   ❌   |   ❌    |  ✅   |         ❌         |        ✅        |
-| **Auth0**          |   ✅   |    ✅    |   ❌   |   ❌    |  ✅   |         ✅         |        ✅        |
+| First Sub-Verifier | Google | Twitch | Discord | Email Passwordless | Auth0\* |
+| :----------------- | :----: | :----: | :-----: | :----------------: | :-----: |
+| **Google**         |   ✅   |   ❌   |   ❌    |         ✅         |   ✅    |
+| **Twitch**         |   ❌   |   ✅   |   ❌    |         ❌         |   ❌    |
+| **Discord**        |   ❌   |   ❌   |   ✅    |         ❌         |   ❌    |
+| **Email P'less**   |   ✅   |   ❌   |   ❌    |         ✅         |   ✅    |
+| **Auth0\***        |   ✅   |   ❌   |   ❌    |         ✅         |   ✅    |
+
+\*Auth0 column also includes Custom JWT, AWS Cognito, and Firebase providers when the JWT verifier
+identifier is email.
 
 :::info Important
 
-Some login methods (like Twitch and Discord) cannot be combined with others because they lack a
-**common identifier**, such as an email. This identifier is crucial for connecting user accounts
-across different authentication methods and ensuring reliable user recognition when switching
-between login methods.
+- **Twitch** and **Discord** can only be aggregated with themselves (self-aggregate).
+- **Google** and **Email Passwordless** can always be aggregated with each other.
+- **Google** and **Email Passwordless** can also be aggregated with Auth0, Custom JWT, AWS Cognito,
+  and Firebase providers, but only when the JWT user identifier is set to email.
 
 :::
 
+Some login methods cannot be combined with others because they lack a **common identifier**, such as
+an email. This identifier is crucial for connecting user accounts across different authentication
+methods and ensuring reliable user recognition when switching between login methods.
+
 ### Auth0 Special Capabilities
 
 When using Auth0 as a verifier, you have access to a wide range of authentication methods. After

docs/connect-blockchain/connect-blockchain.mdx

@@ -41,10 +41,10 @@ transactions, smart contract wallets, different elliptic curve pairs and even RS
 
 ## Private Key Providers (PnP & SFA)
 
-The Private Key Providers work with the majority of Web3Auth products, including Plug and Play SDKs,
-Single Factor Auth SDKs, and tKey SSS (v1) SDKs. As the name suggests these providers are a wrapper
-around the user's private key, which is dynamically reconstructed with Shamir's Secret Sharing and
-is present in the user's frontend.
+The Private Key Providers work with the majority of Web3Auth products, including Plug and Play SDKs
+and Single Factor Auth SDKs. As the name suggests these providers are a wrapper around the user's
+private key, which is dynamically reconstructed with Shamir's Secret Sharing and is present in the
+user's frontend.
 
 Once the authentication happens, the returned result from the Web3Auth network is taken up by the
 provider to give a common interface to interact with the blockchain of your choice. Currently,

docs/infrastructure/mpc-architecture.mdx

@@ -12,15 +12,11 @@ import TkeyMpcFlowDark from "@site/static/images/tkey-mpc-flow-dark.png";
 import TkeyMpcFlowLight from "@site/static/images/tkey-mpc-flow-light.png";
 
 This document provides an in-depth exploration of the technical architecture of the MPC-based SDKs,
-this includes the tKey MPC SDK and CoreKit MPC SDK (a rundown of our SDKs
-[here](/how-web3auth-works/)).
+this includes the MPC Core Kit SDKs.
 
 The only difference between the SSS-based SDKs and MPC SDKs are that during usage/login MPC SDKs do
 not reconstruct user private keys.
 
-While the tKey MPC SDK, supports multiple configurations like 2/n, 2/2 flows, this documentation,
-for simplicity, focuses on a 2/3 setup.
-
 ## Overview of Cryptographic and Blockchain Support (compatibility and implementations)
 
 Web3Auth supports most popular blockchains & elliptic curves out there. In particular, out of the
@@ -58,8 +54,8 @@ much more convienent. Notably, but non-exhaustively, Web3Auth supports:
 
 ## User Key Overview
 
-Web3Auth uses tKey MPC to manage user wallets in a distributed fashion, leveraging various factors
-or shares managed by users, including their devices, private inputs, backup locations, and cloud
+Web3Auth uses MPC to manage user wallets in a distributed fashion, leveraging various factors or
+shares managed by users, including their devices, private inputs, backup locations, and cloud
 service providers. As long as a user can access 2 out of n (2/n) of these shares, they can access
 their key. This distributedly secure key is called the $TSSKey$.
 
@@ -99,8 +95,7 @@ $z_1,z_2 \in \mathbb{Z}_q$.
 
 This key's storage process mirrors that of the TSSKey, with the primary difference being that the
 metadataKey is always reconstructed and used for encryption/decryption tasks. It's based on the
-fundamental Shamir’s Secret Sharing scheme and initially generated on the user's front-end. Readers
-can further reference tKey v1 flows used by the metadataKey in our SSS Infrastructure Documentation.
+fundamental Shamir’s Secret Sharing scheme and initially generated on the user's front-end.
 
 ## Other components
 
@@ -188,7 +183,7 @@ Signaures.
 
 The TSS signing requires information from two sections:
 
-- shared information (eg. public key, share commitments, theshold, unique identifiers)
+- shared information (eg. public key, share commitments, theeshold, unique identifiers)
 - local information (eg. TSS key share).
 
 The shared information is stored on metadata and replicated, whereas the local information is kept

docs/infrastructure/sss-architecture.mdx

@@ -11,17 +11,13 @@ import KeyReconstructionFlow from "@site/static/images/key-reconstruction-sss-fl
 import SSSArchitectureFlow from "@site/static/images/sss-architecture-flow.png";
 
 This document provides an in-depth exploration of the technical architecture of the Shamir's Secret
-Sharing(SSS)-based SDKs, this includes the current Plug and Play SDKs, tKey SSS SDKs (a rundown of
-our SDKs [here](/how-web3auth-works/)).
+Sharing(SSS)-based SDKs, this includes the current Plug and Play & Single Factor Auth SDKs.
 
 Shamir's Secret Sharing is a base form of MPC that splits a secret into $n$ shares, of which
 threshold $t$ are required to reconstruct the secret. You maybe looking for the
 [MPC Architecture documentation](/infrastructure/mpc-architecture/) instead which does not require
 the key to be reconstructed on usage.
 
-While the tKey SSS SDK, supports multiple configurations like 2/n, 2/2 flows, or m/n flows, this
-documentation, for simplicity, focuses on a 2/3 setup.
-
 ## Components
 
 The accompanying image illustrates the typical flow of wallet management within the SSS