About · what PBI is (and isn’t)
A strict presence primitive for irreversible actions.
PBI is intentionally narrow: it proves a human was present for a specific operation. You hash the action, issue a single-use challenge bound to that hash, require a live WebAuthn UP+UV ceremony, then mint a signed, non-replayable receipt. Optional proof bundles can be exported for offline verification and audit workflows.
Proof of presence
UP+UV ceremony occurred for a single-use challenge bound to an action hash, within expiry.
Evidence, not vibes
Receipts are verifiable by hash long after the event—useful for disputes and forensics.
No biometric storage
Biometrics stay on the device; PBI verifies the WebAuthn assertion and stores receipts.
Drop-in hardening
Keep SSO/OAuth/JWT. Add PBI only where the blast radius is highest.
Positioning
What PBI is (and what it isn’t)
Enterprise teams move faster when the primitive is defined precisely. PBI is evidence of presence for an action — not identity resolution.
PBI is
A presence gate for irreversible actions: single-use, time-bounded challenge + UP+UV ceremony + receipt as cryptographic evidence.
PBI is not
KYC, identity verification, or biometrics storage. It does not tell you who a person is—only that a live presence ceremony occurred.
PBI integrates with
Your existing auth stack (SSO/OAuth/JWT), your audit systems, and your billing model via action-level verification events.
Why “presence” is the missing layer
Most breaches don’t start with “no authentication”—they start with “authentication happened earlier, then the approval was silently delegated.” PBI forces the approval to happen at execution time, bound to the exact action hash.
Vocabulary
Core terms (so everyone speaks precisely)
These definitions are procurement-friendly and security-review-friendly: strict, testable, and non-magical.
Action
Definition
The irreversible operation you are about to execute (transfer, rotate keys, deploy, grant admin).
Canonical action
Definition
A normalized serialization of that operation (stable fields, deterministic formatting).
actionHash
Definition
SHA-256 of the canonical action. This is what the challenge is bound to.
Challenge
Definition
A single-use server-issued token bound to actionHash and expiry; rejects replay.
UP+UV
Definition
User Presence + User Verification: authenticator requires a live biometric ceremony.
Receipt
Definition
Signed evidence that verification occurred for a bound actionHash within constraints.
Portable proof
Definition
Optional export format for offline verification under a trust policy (rotate/revoke/expire).
Integration
Where PBI fits in a real system
PBI sits at the enforcement point. You keep normal auth for most endpoints, and apply PBI only where you need proof.
Rollout pattern (works in enterprise)
Pick 1 endpoint with the highest blast radius. Add a presence gate. Measure fraud reduction and dispute clarity. Expand to other irreversible operations after you prove velocity and reliability.
Start: treasury / money out
Make payout approval provable. Disputes become receipts, not arguments.
Then: admin control plane
Grant/revoke roles and rotate keys only under UP+UV.
Then: deploy / production changes
Require presence proof for release and config actions.
FAQ
Quick answers
Short, enterprise-friendly answers that keep implementation and review aligned.
Do users need an account with PBI?
Not for the proof itself. Your app decides how identity maps to a user. PBI proves presence for a specific action via WebAuthn.
Is this compatible with passkeys?
Yes. PBI uses standard WebAuthn. Passkeys are a great fit because they’re biometric-backed and phishing-resistant.
What if verification fails?
You do not proceed. Treat any non-VERIFIED decision as a hard deny for irreversible actions.