Signing

Every 1auth signature involves two layers: the 1auth signing dialog, which prepares and verifies the payload, and the browser's WebAuthn prompt, which the user must always approve. The one UX decision an integrator makes is who shows the human-readable review before that prompt:

• Blind signing (default): the signing dialog stays hidden and your app is the review UI.
• Clear signing: a visible 1auth review iframe appears before the passkey prompt.

Blind signing

By default, the SDK opens the 1auth signing dialog in invisible mode, hands it the signable payload, and resolves once the passkey ceremony and the signing or execution result return. 1auth renders no review UI of its own. The browser's WebAuthn prompt is always shown; nothing is signed without a user gesture.

Optionally, present the complete action in your own UI (recipient, amount, token, chain, fees, and risk context) before invoking the SDK. Checkout pages that display the payment details next to the buy button are the canonical fit; see Checkout.

"Blind" describes the review UX, not the security model. The server still binds and verifies the exact prepared intent, WebAuthn challenge, browser origin, RP ID, account, and credential before submitting anything on-chain, so your app cannot swap the payload after the user approves.

Choosing a mode

Keep blind signing when your app owns a complete review UX. Enable clear signing while you are still building that UX, or when you want users to see the authoritative 1auth-prepared action before approving.

Clear signing

Shows the 1auth transaction, message, or EIP-712 review iframe before the user approves the browser or platform passkey prompt. The API can change while the review UX and integration contract are validated.

Enable

Set experimental_clear_signing: true on OneAuthClient:

import { OneAuthClient } from "@rhinestone/1auth";
 
export const client = new OneAuthClient({
  providerUrl: "https://passkey.1auth.app",
  clientId: "wallet-dashboard",
  experimental_clear_signing: true,
  sponsorship: {
    accessTokenUrl: "/api/sponsorship/access-token",
    extensionTokenUrl: "/api/sponsorship/extension-token",
  },
});

Supported signing calls from this client show the review iframe before WebAuthn starts. Authentication, signup, recovery, and permission grants are unchanged.

Review UX is independent of WebAuthn placement: clear signing works in both app-origin and experimental cross-origin mode. See Choose your WebAuthn mode.

Supported methods

• sendIntent()
• sendBatchIntent()
• signMessage()
• signTypedData()
• signWithModal()
• createPasskeyWalletClient() signing and sendCalls() flows

App-origin sendIntent() also supports the experiment: the 1auth iframe shows the authoritative review, then WebAuthn still runs on the integrating application's own origin after approval. See App-origin passkeys.

Per-call overrides

Enable the experiment for one request:

await client.signMessage({
  accountAddress,
  message: "Approve checkout order #123",
  experimental_clear_signing: true,
});

Disable it for one request on a client that enabled it globally:

await client.sendIntent({
  accountAddress,
  targetChain: 8453,
  calls: [paymentCall],
  experimental_clear_signing: false,
});

For viem wallet-client integrations, enable it on the factory because the factory creates its own internal OneAuthClient:

const walletClient = createPasskeyWalletClient({
  accountAddress,
  clientId: "wallet-dashboard",
  chain,
  transport,
  experimental_clear_signing: true,
});

What users see

The review iframe renders the signable action before WebAuthn:

• verified actions from 1auth's clear-signing registry,
• decoded ERC-20 transfers and approvals when possible,
• app-supplied ABI labels marked as app supplied,
• raw contract calls when no safe decode exists,
• chain, amount, recipient, and policy details when available.

Verified badges only come from 1auth's registry. App-supplied ABI metadata can make a custom contract readable, but it is not marked verified.

Signing vs Headless Mode

Both blind and clear signing use 1auth's passkey signer: the user's passkey produces the signature, with or without a visible 1auth review.

Headless Mode is different: your app provides signatures from another validator or signer, and 1auth does not run the passkey signing dialog at all.