Why PBI exists · evidence, not “logs”
Sessions prove access. They don’t prove presence.
The modern web assumes: “if the session is valid, the user approved the action.” That assumption is where irreversible damage happens: stolen tokens, replay, automation, insider edits, and dispute chaos. PBI exists to replace that assumption with a strict ceremony: bind intent to an action hash, require a live UP+UV WebAuthn presence check, and mint a signed, non-replayable receipt.
Replace “trust” with proof
Receipts are cryptographic evidence tied to a ceremony, not mutable rows in a database.
Eliminate silent approvals
High-risk actions must pass UP+UV and single-use challenge constraints.
Win disputes fast
Receipts and optional portable proofs are verifiable later by hash, even offline.
Keep your existing auth
PBI hardens actions; it doesn’t replace SSO/OAuth/JWT.
The failure mode
Why “logged in” is not the same as “approved”
Enterprise breaches and fraud often share a boring root cause: a valid session was treated as a valid approval. Tokens travel; humans don’t.
Session theft
Phishing, malware, token replay, leaked cookies. The server sees a valid token and executes irreversible actions.
Automation & delegated scripts
Bots can act inside a session. “Approved” becomes a side effect, not an intentional act.
Dispute chaos
Weeks later, you have logs and screenshots—no cryptographic evidence that a human was present for that exact action.
The real question security teams can’t answer
Not “who had access?” — but: “Was a human physically present and knowingly authorizing this exact operation?”
Audit reality
Logs are not receipts
Most audit trails are mutable by insiders, vulnerable to post-incident edits, and hard to dispute. PBI receipts are evidence: action-bound, single-use, time-bounded, and verifiable later.
Legacy vs PBI (what changes)
Legacy stacks stitch together identity + sessions + logs. PBI adds one missing primitive: presence proof for the action itself.
Legacy (common today)
PBI (presence-bound)
Login proves access
Presence ceremony proves approval for this action hash (UP+UV)
Session token authorizes everything
Single-use challenge authorizes exactly one intended operation
Audit log row is editable
Receipt is cryptographic evidence tied to a signed verification decision
Disputes rely on screenshots
Disputes rely on verifiable receipt hash (and optional portable proofs)
Admins can erase trails
Offline verification + trust policy can be designed to be tamper-evident
The fix
Presence becomes a strict, enforceable gate
PBI is intentionally narrow: it hardens irreversible actions. You keep your identity stack. You add PBI only where “maybe” is unacceptable.
Bind intent
Canonicalize the action and hash it. The challenge is bound to that action hash.
Require UP+UV
FaceID/TouchID proves a human is present. No passwords. No biometrics stored by you.
Mint evidence
Receipt hash becomes your durable reference for audit, forensics, and disputes.
Guarantees
What PBI proves (and what it does not)
This is critical for enterprise trust: we state guarantees precisely and avoid unverifiable claims.
PBI proves
A UP+UV WebAuthn ceremony occurred for a single-use, time-bounded challenge bound to this action hash; the server verified it and minted a receipt.
PBI does not prove
Who the user is in the real world (KYC), or their role/identity beyond the credential used. PBI is presence + intent evidence, not identity resolution.
You control enforcement
PBI is only powerful if you gate the action. Rule: if verify doesn’t return PBI_VERIFIED, you do not proceed.
Where teams deploy PBI first
Start with one endpoint where the blast radius is highest. Prove ROI in a week. Expand coverage across your irreversible operations.
Treasury & payouts
Wires, payouts, escrow release, withdrawals, settlement actions.
Admin control plane
Role grants, key rotation, production config, incident actions.
Governance actions
Proposal approval, policy changes, privileged operations.
FAQ
Common questions
These are the questions enterprise teams ask in the first 10 minutes. Answering them clearly speeds procurement and integration.
Is this just MFA?
No. MFA is typically a login/session step. PBI is action-level presence proof bound to a specific action hash, emitting a receipt as evidence.
Does PBI replace SSO / OAuth / JWT?
No. Keep your existing identity. PBI hardens specific irreversible actions by requiring a UP+UV presence ceremony at execution time.
Do you store biometrics?
No. WebAuthn biometrics never leave the device. PBI verifies the WebAuthn assertion and stores receipt metadata and hashes.
What do we store to be audit-ready?
At minimum: receiptHash + decision + actionHash reference + timestamps. For offline workflows: optional portable proof bundles under a trust policy.
How do we roll this out without breaking UX?
Gate only 1–3 irreversible endpoints first. Keep all other operations session-based. Users only see the presence ceremony when it truly matters.