> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rhinestone.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Passkeys and domains

> Understand domain-bound passkeys, share accounts across subdomains, and troubleshoot origin configuration.

Embedded wallets create and use passkeys on your application's domain. The [standard client setup](/wallets/embedded-wallets/accounts#initialize-the-client) uses this behavior without a separate opt-in. By default, each hostname has a separate passkey and smart-account namespace, even when the user signs in with the same email or OAuth identity.

## How domains determine the account

* **RP ID** (relying party ID) is the passkey's hostname namespace, such as `checkout.example.com`. It contains no scheme or port.
* **Origin** is the exact page origin that runs WebAuthn, such as `https://checkout.example.com`. It includes the scheme and any non-default port, but no path.
* **Account namespace** is `https://<rpId>`. The RP ID determines which passkey, signer, and smart account the user accesses.

For `https://checkout.example.com`, the defaults are:

```text theme={null}
RP ID:              checkout.example.com
Origin:             https://checkout.example.com
Account namespace: https://checkout.example.com
```

The browser supplies and signs the origin; the SDK cannot replace it. A different port changes the origin that must be authorized, but not the account namespace. A different hostname changes the default RP ID and therefore the account.

## Share an account across subdomains

To let a user access the same passkey and account from `app.example.com` and `checkout.example.com`, choose their parent domain, `example.com`, as the RP ID **before onboarding users**.

1. Follow the [Dashboard RP configuration](/home/resources/dashboard#configure-the-rp-id-and-authorized-origins) to verify the domains, register `example.com` as the RP ID, and authorize both exact origins.
2. Add the matching option to the shared [client initializer](/wallets/embedded-wallets/accounts#initialize-the-client) on both subdomains:

```ts theme={null}
webauthn: {
  rpId: "example.com",
},
```

3. Authenticate as the same user on each origin with the browsers and password managers you support. Confirm that both return the same account address before rollout.

<Note>
  Dashboard configuration authorizes the shared namespace; `webauthn.rpId` selects it in the client. Without that client option, each hostname keeps its own namespace. `rpOrigins` is server configuration, not an SDK option.
</Note>

## Changing domains

<Warning>
  Changing the RP ID selects a different passkey, signer, and smart account. Existing balances do not move automatically. Treat this as an account migration, not a routine configuration update.
</Warning>

Moving to a new hostname changes the RP ID when you use the default hostname-based configuration. Moving between subdomains with the same explicitly configured parent RP ID keeps the namespace, but the new origin must still be verified and authorized in the Dashboard. An established RP ID cannot be changed or cleared in the Dashboard.

## Troubleshoot domain configuration

| Symptom                                     | What to check                                                                                                                                                                           |
| ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Authentication fails on a deployed host     | Use HTTPS, including for local development against the hosted provider. Check that the exact origin is authorized, including any non-default port.                                      |
| A configured RP ID is rejected              | It must be the current hostname or an eligible parent domain, verified and configured in the Dashboard. Unrelated domains and wildcard ceremony origins are unsupported.                |
| Subdomains return different accounts        | Check that every client explicitly sets the same `webauthn.rpId` and that the Dashboard authorizes each origin for it. Signing in with the same identity alone does not share accounts. |
| A domain change appears to lose the account | Compare the old and new RP IDs. A different namespace resolves to a different account; it does not transfer the original account's balances.                                            |

`clientId` identifies the registered application; it does not override browser-origin verification. If authentication succeeds but a transaction fails, check [sponsorship setup](/transactions/sponsorship/set-up) separately.