Browser signing and wallet permissions

The Sigma signer runs on the auth origin inside the user's browser. It can ask the user to unlock the selected identity and perform supported signing/encryption operations. This is different from the application member key used on your backend for OAuth token exchange.

CWI signer lifecycle

import { SigmaCWISigner } from "@sigma-auth/better-auth-plugin/client";

export async function signWithSigma(bapId: string, requestPath: string, body?: string) {
  const signer = new SigmaCWISigner("https://auth.sigmaidentity.com");
  try {
    await signer.init();
    signer.setIdentity(bapId);
    return await signer.sign(requestPath, body);
  } finally {
    signer.destroy();
  }
}

Run this in browser code initiated by the user's action. Choose an identity the user controls. Keep the request path and serialized body consistent with the receiving API's verification contract. A valid signature is not permission for an unrelated operation.

SigmaCWISigner exposes sign, signAIP, encrypt, decrypt, getFriendPublicKey, setIdentity, getIdentity, isReady, and destroy in the audited package. SigmaIframeSigner is a separate legacy message transport; do not mix message protocols or invent postMessage shapes. LocalServerSigner targets a separately operated local signer and is not a hosted URL shortcut.

Browser requirements

Iframe and cross-site cookie restrictions can prevent an embedded session from being available. Show a clear pending/unlock/error state and provide a supported top-level sign-in path when needed. Do not weaken origin validation, expose cookies to JavaScript, or accept messages from arbitrary windows to make embedding work.

Keep signer instances scoped to the UI that needs them and destroy them on unmount. Do not leave pending requests or unlocked views alive after an identity switch. Ask for signing only when the user understands the request.

Key export and certificates

Signing does not require exporting a key to the application. Treat any explicit encrypted key-export feature as a separate sensitive user operation, not a prerequisite for ordinary integration.

Certificate acquire/list/prove/relinquish operations use the BRC-100 wallet interface and its permission boundaries, described in wallet credentials. A CWI signing example does not prove interoperability with every wallet or enable gated certificate issuance.