From b96aa3165c62e1dc9e27258d6b2ce6a7fc7594b0 Mon Sep 17 00:00:00 2001 From: Brandon Corbett Date: Mon, 7 Sep 2026 07:39:03 -0400 Subject: [PATCH] docs: synced passkeys are allowed by default The auth API defaults authenticator_policy.syncedPasskeys to allow, so a stock deployment enrols iCloud Keychain and Google Password Manager passkeys rather than refusing them. synced_passkey_not_allowed is still reachable, since a deployment issuing its own authenticators sets block and the SDK cannot tell from the client which way the API is configured. The guidance to branch on the code rather than render the message is unchanged. --- AGENTS.md | 7 ++++--- README.md | 14 +++++++------- 2 files changed, 11 insertions(+), 10 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index b84c833..0f62d9b 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -252,9 +252,10 @@ sentence: `synced_passkey_not_allowed`, `authenticator_not_allowed`, or `prf_required`. The adapter forwards that body verbatim, and `extractMessage` turns the code into `error.message`, so callers must branch with `getPasskeyPolicyErrorCode()` rather than render the message. The API's -`authenticator_policy.syncedPasskeys` defaults to `block` and every iCloud -Keychain or Google Password Manager passkey is backup eligible, so this is the -default path, not an edge case. +`authenticator_policy.syncedPasskeys` defaults to `allow`, so a stock deployment +enrols these, but a deployment that sets `block` refuses every iCloud Keychain +and Google Password Manager passkey. The SDK cannot tell which way it is +configured, so treat the refusal as reachable rather than exceptional. `@seamless-auth/types` publishes no union for those codes as of 0.15.0, so `PasskeyPolicyErrorCode` in `src/client/errors.ts` is a local copy of the API's diff --git a/README.md b/README.md index 84cb7d5..3bb914d 100644 --- a/README.md +++ b/README.md @@ -644,11 +644,11 @@ switch (getPasskeyPolicyErrorCode(error)) { `attachment_not_allowed` is refused before any ceremony runs, so the browser never prompts. The rest are refused after a credential exists and can be inspected. -`syncedPasskeys` defaults to `block` on the Seamless Auth API. Passkeys created by iCloud Keychain -and Google Password Manager are backup eligible, so on a default deployment the most common consumer -passkey is refused at registration. If that is not what you want, set -`authenticator_policy.syncedPasskeys` to `allow` in the API's system config; the SDK cannot relax it -from the client. +`syncedPasskeys` defaults to `allow` on the Seamless Auth API, so a default deployment enrols the +passkeys iCloud Keychain and Google Password Manager create. A deployment that issues its own +authenticators can set `authenticator_policy.syncedPasskeys` to `block` in the API's system config, +and every backup-eligible passkey is then refused at registration. Handle the code: the SDK cannot +tell from the client which way the API is configured. Like `getOAuthErrorCode()`, this returns `undefined` for anything it does not recognize, including codes added by a newer API, so an unexpected refusal keeps your generic messaging. @@ -1071,8 +1071,8 @@ email sends to a signed-in user. Using `@seamless-auth/react` with an older adap `GET` forms returns a 404 for those requests. See the changelog for the minimum adapter version. `/webAuthn/register/finish` can refuse a verified credential on policy grounds with a `403` whose -body is a stable code. `syncedPasskeys` defaults to `block`, which refuses every backup-eligible -passkey, so this is reachable on a default deployment. See +body is a stable code. `syncedPasskeys` defaults to `allow`, but a deployment that sets `block` +refuses every backup-eligible passkey, so handle the code rather than assuming the default. See [Passkey policy refusals](#passkey-policy-refusals). ## Notes