Browser encryption & UI Components
Encrypt sensitive values in the page, against your tenant’s public key, so plaintext (a card number, an SSN) never touches your servers. You store and transmit only a portablekc: ciphertext — and only KnoxCall, holding the private key, can decrypt it. No API key is ever shipped to the browser.
This is how you collapse a payment/PII frontend toward PCI SAQ A.
1. Client-side encryption (@knoxcall/browser)
Your backend fetches a sealing bundle (the tenant public key + a key reference — no private material) and hands it to the page. Encryption is then a pure client-side operation with no network round-trip.
kc: value you produce here decrypts through /v1/decrypt, a Relay route-action, or a data-plane enclave.
2. Reveal to the browser without an API key
To show a user one decrypted value, your backend mints a single-use, payload-pinned capability token (see client-side reveal) and the page exchanges it once:3. Iframe UI Components (@knoxcall/react)
For the strongest isolation, capture and display data inside a cross-origin iframe served from a KnoxCall origin. The host page — and any XSS on it — never sees the raw PAN; your callback receives only the kc: ciphertext plus non-sensitive display bits (last4/brand).
<Reveal> is the mirror: it decrypts (or detokenizes) with a capability token and displays the value inside the iframe, so plaintext is shown to the user but never crosses into your JavaScript.