@swype-org/react-sdk 0.1.87 → 0.1.89

package/dist/index.d.cts

@@ -391,19 +391,16 @@ interface SwypePaymentProps {
 declare function SwypePayment(props: SwypePaymentProps): react_jsx_runtime.JSX.Element;
 
 /**
- * Cross-origin iframe passkey delegation via postMessage.
+ * Cross-origin iframe passkey helpers.
  *
  * When the webview-app runs inside a cross-origin iframe, WebAuthn
  * ceremonies cannot execute from within the iframe on Safari. For passkey
  * creation, we first attempt a direct `navigator.credentials.create()`
  * call (works in Chrome/Firefox with the iframe permissions policy). If
  * that fails (Safari), we open a same-origin pop-up window on the Swype
- * domain to perform the ceremony, then relay the result back via
- * `BroadcastChannel` (Safari strips `window.opener` from popups opened
- * by cross-origin iframes, so `postMessage` via opener doesn't work).
- *
- * Passkey *assertion* (`navigator.credentials.get`) still delegates to
- * the parent page via postMessage as before.
+ * domain to perform the ceremony. The popup writes the result to the
+ * server with a verification token, and the opener reads from the server
+ * after the popup closes.
  */
 /**
  * Thrown when `navigator.credentials.create()` fails inside a
@@ -431,7 +428,7 @@ interface PasskeyPopupOptions {
     };
     timeout?: number;
     /** Populated by `createPasskeyViaPopup`; not set by callers. */
-    channelId?: string;
+    verificationToken?: string;
     /** Privy JWT so the popup can register the passkey server-side. */
     authToken?: string;
     /** Core API base URL for server-side passkey registration. */
@@ -442,24 +439,14 @@ interface PasskeyPopupOptions {
  * passkey creation. Used as a fallback when Safari blocks
  * `navigator.credentials.create()` inside a cross-origin iframe.
  *
- * Communication uses `BroadcastChannel` because Safari strips
- * `window.opener` from popups opened by cross-origin iframes.
- * Falls back to `window.postMessage` for browsers that preserve the
- * opener reference.
- *
- * When both client-side channels are blocked (Safari ITP partitions
- * BroadcastChannel by top-level origin), the popup registers the
- * passkey directly with the backend. On popup close, this function
- * checks the server for newly registered passkeys as a final fallback.
+ * The popup registers the passkey with the server using a verification
+ * token. After the popup closes, this function checks the server for
+ * the passkey matching the token.
  *
  * Must be called from a user-gesture handler (e.g. button click) to
  * avoid the browser's pop-up blocker.
- *
- * @param existingCredentialIds - Credential IDs known before the popup
- *   opens. Used to diff against server state when the popup closes
- *   without delivering a client-side result.
  */
-declare function createPasskeyViaPopup(options: PasskeyPopupOptions, existingCredentialIds?: string[]): Promise<{
+declare function createPasskeyViaPopup(options: PasskeyPopupOptions): Promise<{
     credentialId: string;
     publicKey: string;
 }>;
@@ -467,8 +454,6 @@ interface PasskeyVerifyPopupOptions {
     credentialIds: string[];
     rpId: string;
     /** Populated by `findDevicePasskeyViaPopup`; not set by callers. */
-    channelId?: string;
-    /** Populated by `findDevicePasskeyViaPopup`; not set by callers. */
     verificationToken?: string;
     /** Privy JWT so the popup can report verification server-side. */
     authToken?: string;
@@ -483,10 +468,9 @@ interface PasskeyVerifyPopupOptions {
  * inside a cross-origin iframe. The popup runs on the Swype domain where
  * the rpId matches, so WebAuthn works.
  *
- * When `authToken` and `apiBaseUrl` are provided, the popup also writes a
- * verification token to the backend. If Safari's ITP blocks both
- * BroadcastChannel and window.opener.postMessage, the opener falls back to
- * checking the server for the matching token after the popup closes.
+ * The popup writes a verification token to the server. After the popup
+ * closes, the opener checks the server for the matching token to determine
+ * which credential was verified.
  *
  * Must be called from a user-gesture handler (e.g. button click) to
  * avoid the browser's pop-up blocker.

package/dist/index.d.ts

@@ -391,19 +391,16 @@ interface SwypePaymentProps {
 declare function SwypePayment(props: SwypePaymentProps): react_jsx_runtime.JSX.Element;
 
 /**
- * Cross-origin iframe passkey delegation via postMessage.
+ * Cross-origin iframe passkey helpers.
  *
  * When the webview-app runs inside a cross-origin iframe, WebAuthn
  * ceremonies cannot execute from within the iframe on Safari. For passkey
  * creation, we first attempt a direct `navigator.credentials.create()`
  * call (works in Chrome/Firefox with the iframe permissions policy). If
  * that fails (Safari), we open a same-origin pop-up window on the Swype
- * domain to perform the ceremony, then relay the result back via
- * `BroadcastChannel` (Safari strips `window.opener` from popups opened
- * by cross-origin iframes, so `postMessage` via opener doesn't work).
- *
- * Passkey *assertion* (`navigator.credentials.get`) still delegates to
- * the parent page via postMessage as before.
+ * domain to perform the ceremony. The popup writes the result to the
+ * server with a verification token, and the opener reads from the server
+ * after the popup closes.
  */
 /**
  * Thrown when `navigator.credentials.create()` fails inside a
@@ -431,7 +428,7 @@ interface PasskeyPopupOptions {
     };
     timeout?: number;
     /** Populated by `createPasskeyViaPopup`; not set by callers. */
-    channelId?: string;
+    verificationToken?: string;
     /** Privy JWT so the popup can register the passkey server-side. */
     authToken?: string;
     /** Core API base URL for server-side passkey registration. */
@@ -442,24 +439,14 @@ interface PasskeyPopupOptions {
  * passkey creation. Used as a fallback when Safari blocks
  * `navigator.credentials.create()` inside a cross-origin iframe.
  *
- * Communication uses `BroadcastChannel` because Safari strips
- * `window.opener` from popups opened by cross-origin iframes.
- * Falls back to `window.postMessage` for browsers that preserve the
- * opener reference.
- *
- * When both client-side channels are blocked (Safari ITP partitions
- * BroadcastChannel by top-level origin), the popup registers the
- * passkey directly with the backend. On popup close, this function
- * checks the server for newly registered passkeys as a final fallback.
+ * The popup registers the passkey with the server using a verification
+ * token. After the popup closes, this function checks the server for
+ * the passkey matching the token.
  *
  * Must be called from a user-gesture handler (e.g. button click) to
  * avoid the browser's pop-up blocker.
- *
- * @param existingCredentialIds - Credential IDs known before the popup
- *   opens. Used to diff against server state when the popup closes
- *   without delivering a client-side result.
  */
-declare function createPasskeyViaPopup(options: PasskeyPopupOptions, existingCredentialIds?: string[]): Promise<{
+declare function createPasskeyViaPopup(options: PasskeyPopupOptions): Promise<{
     credentialId: string;
     publicKey: string;
 }>;
@@ -467,8 +454,6 @@ interface PasskeyVerifyPopupOptions {
     credentialIds: string[];
     rpId: string;
     /** Populated by `findDevicePasskeyViaPopup`; not set by callers. */
-    channelId?: string;
-    /** Populated by `findDevicePasskeyViaPopup`; not set by callers. */
     verificationToken?: string;
     /** Privy JWT so the popup can report verification server-side. */
     authToken?: string;
@@ -483,10 +468,9 @@ interface PasskeyVerifyPopupOptions {
  * inside a cross-origin iframe. The popup runs on the Swype domain where
  * the rpId matches, so WebAuthn works.
  *
- * When `authToken` and `apiBaseUrl` are provided, the popup also writes a
- * verification token to the backend. If Safari's ITP blocks both
- * BroadcastChannel and window.opener.postMessage, the opener falls back to
- * checking the server for the matching token after the popup closes.
+ * The popup writes a verification token to the server. After the popup
+ * closes, the opener checks the server for the matching token to determine
+ * which credential was verified.
  *
  * Must be called from a user-gesture handler (e.g. button click) to
  * avoid the browser's pop-up blocker.