update

apps/nextra/pages/en/build/guides/aptos-federated-keyless/key-considerations.mdx

@@ -6,11 +6,11 @@ title: "Federated Keyless Key Considerations"
 
 **Supported IAMs**
 
-Currently, the three supported IAMs are Amazon Cognito, Auth0, and Okta across devnet, testnet, and mainnet. See a table of the full set of supported IAM providers [here](oidc-support.mdx).
+Currently, the three supported IAMs are Amazon Cognito, Auth0, and Okta across devnet, testnet, and mainnet. See a table of the full set of supported IAM providers [here](../aptos-keyless/oidc-supportion-guide.mdx).
 
 **Federated Keyless flow**
 
-The flow for Federated Keyless transactions is the same as described [here](how-keyless-works.mdx). However, the difference is that in Federated Keyless, instead of the OIDC provider (e.g. Google, Apple) acting as the issuer of the JWT, the IAM provider (e.g. Auth0, Cognito) acts as the issuer. The user authenticates with the application, the IAM receives the user’s credentials, and then the IAM issues the Keyless-compatible JWT.
+The flow for Federated Keyless transactions is the same as described [here](../aptos-keyless/how-keyless-works.mdx). However, the difference is that in Federated Keyless, instead of the OIDC provider (e.g. Google, Apple) acting as the issuer of the JWT, the IAM provider (e.g. Auth0, Cognito) acts as the issuer. The user authenticates with the application, the IAM receives the user’s credentials, and then the IAM issues the Keyless-compatible JWT.
 
 **Available authentication methods**
 

apps/nextra/pages/en/build/guides/aptos-federated-keyless/other.mdx

@@ -2,19 +2,22 @@
 title: "FAQ"
 ---
 
-## Frequently Asked Questions
+## Federated Keyless FAQs
 
 **What if I stop using my IAM for my application? What if I switch IAM providers?**
 
 - An account address depends on values of several variables that are specific to an IAM service, including `aud` (client ID) and `iss` (issuer).  If these values are changed, then a different address will be derived. 
 - If you want to switch IAM providers, you will need to develop an account migration flow, resulting in a key rotation from the account derived from the prior IAM provider to the account derived from the new IAM provider. 
-- We recommend allowing your users to add a secondary authentication method to their accounts (e.g. back-up private key) so that they can maintain access should the authentication path into their account via Federated Keyless is disrupted via service provider change
+- We recommend allowing your users to add a secondary authentication method to their accounts (e.g. back-up private key) so that they can maintain access should the authentication path into their account via Federated Keyless be disrupted via a service provider change. In order to implement this, you need to do a key rotation to a multikey account. For relevant documentation see [key rotation](https://aptos.dev/en/build/guides/key-rotation) and [multikey SDK](https://aptos-labs.github.io/aptos-ts-sdk/@aptos-labs/ts-sdk-1.29.1/classes/MultiKeyAccount.html).
 
-**How do I make sure my users can continue accessing their accounts?**
+**Does using an IAM cost money?**
 
-- We recommend allowing your users to add a secondary authentication method to their accounts (e.g. back-up private key) so that they can maintain access should the authentication path into their account via Federated Keyless is disrupted via service provider change or other 
- (In some future I would love to be able to tell users that email backup is possible)
+- Yes, IAMs usually cost money, but they can help provide useful functionality within your application such as role-based access control (authorization), user management, user authentication, security + compliance, and analytics + monitoring.
 
-**What differences in legal considerations between standard keyless and federated keyless?**
+**In the case the dApp or IAM provider goes offline, how do I make sure my users can continue accessing their accounts?**
 
-- Custody - Admin has the ability to impersonate a user.
+- We recommend allowing your users to add a secondary authentication method to their accounts (e.g. back-up private key) so that they can maintain access should the authentication path into their account via Federated Keyless is disrupted via service provider change or other outage.
+
+**I use an open source IAM like Keycloak. Can I use Federated Keyless?**
+
+- Not today. Due to the trust placed in the IAM to have sufficient uptime and security standards, we have limited the accepted IAM set to the currently supported issuers. If you believe your provider should be included for consideration, please consider raising an AIP or contact us in the Keyless developers [telegram](https://t.me/+h5CN-W35yUFiYzkx).