Security overview · strict, testable claims
Proof of presence, minimized data, replay-resistant by design.
PBI is an enforcement primitive: it binds a single-use challenge to an action hash, requires a WebAuthn UP+UV ceremony, and emits a signed receipt. This page explains exactly what is guaranteed, what is stored, and what threats are addressed.
Strict guarantees
UP+UV occurred for a single-use challenge bound to an actionHash within expiry.
Replay resistance
Single-use challenges + expiry windows prevent reuse and delayed approvals.
Evidence receipts
Signed receipt hashes provide durable proof references for audit and disputes.
Data minimization
No biometric storage. No password database. Receipts + metadata only.
Claims
Guarantees vs non-goals
These statements are intentionally narrow and testable. We avoid unverifiable promises.
PBI guarantees
A WebAuthn UP+UV ceremony occurred for a single-use, time-bounded challenge bound to this actionHash, and the server verified it and emitted a receipt.
PBI does not guarantee
Real-world identity (KYC), role correctness, or that an authorized human wasn’t coerced. PBI proves presence and approval ceremony only.
Your enforcement duty
The primitive is only as strong as your gate: irreversible actions must be executed only after PBI_VERIFIED.
Why this matters for security review
Enterprise teams need guarantees stated precisely so they can map them to controls and audits. “We log things” is not a guarantee. “We minted a receipt for a UP+UV ceremony bound to an action hash within expiry” is a guarantee.
Data
What is stored vs not stored
PBI is built to minimize sensitive data. Biometric data stays on the device.
Stored (typical)
Receipt hashes, decisions, timestamps, challenge metadata (expiry/used), and actionHash references for audit mapping.
Not stored
Biometric templates, FaceID/TouchID data, passwords, or a user identity database (unless you choose to map credentials yourself).
Optional exports
Portable proof bundles (pack/proof) for offline verification under a trust policy (rotation/revocation/expiry).
WebAuthn biometrics never leave the device
WebAuthn authenticators perform user verification locally. The server receives an assertion to verify, not biometric material.
Threat model
Threats PBI is designed to reduce
These are the common failure modes in session-based systems where “approved” is inferred, not proven.
Session token theft
PBI moves approval from “session exists” to “presence ceremony occurred now for this action.” Stolen tokens alone are insufficient for gated actions.
Replay & delayed approvals
Single-use challenges and expiry windows prevent replays and delayed submission of old approvals.
Automated or delegated approvals
UP+UV requires a live ceremony. Scripts cannot silently approve irreversible actions without human presence.
Mutable audit trails
Receipts provide cryptographic evidence references (receiptHash) rather than editable log rows as the primary proof artifact.
Dispute ambiguity
Receipts bind actionHash + timing + decision. Disputes become verifications, not arguments.
Over-broad permissions
PBI can narrow approvals to specific actions even when broad roles exist, reducing blast radius of role misuse.
Replay resistance
How replay is prevented
Replay is the silent killer of “approval” systems. PBI is structured to make replay fail by construction.
Single-use challenges
Challenge tokens are one-time. After use, they’re marked used and cannot be replayed.
Expiry windows
Challenges expire. Late approvals are rejected even if the assertion is otherwise valid.
Action binding
The challenge is bound to actionHash. Approvals cannot be repurposed for a different operation.
Decision enforcement
Applications must only proceed when verify returns PBI_VERIFIED. Any other decision is a hard stop.
Operational guidance
Treat verification as part of execution, not a pre-check. Generate the actionHash from the exact operation you are about to perform.
Offline verification
Trust policy: rotation, revocation, expiry
For air-gapped review, compliance exports, and chain-of-custody, PBI supports optional portable proofs that verify offline under a trust policy.
Rotation
Publish new attestor keys while keeping old ones valid for a defined overlap window.
Revocation
Revoke compromised keys and invalidate proofs minted under those keys after the revoke point.
Expiry
Define validity windows for proofs to match policy and reduce long-tail risk.
Offline verification workflow (example)
Portable proofs can be verified without calling the API, using a pinned trust policy bundle.
pbi-pack-verify ./pbi-pack --trust ./trust.json pbi-pack-verify --proof ./proofs/0001.proof.json --trust ./trust.json
Exact filenames and CLI interfaces depend on your deployed tooling; the security model remains the same.
Checklist
Minimum hardening checklist (recommended)
This is the short list security teams ask for when reviewing enforcement primitives.
Required
Canonicalize the action deterministically before hashing (stable serialization).
Required
Bind the challenge to actionHash and enforce single-use + expiry.
Required
Require UP+UV on verify and reject anything else.
Required
Proceed only on PBI_VERIFIED; treat all other decisions as deny.
Required
Store receiptHash + decision + action context for audit mapping.
Required
Define incident response for compromised keys (rotation/revocation policy).
Enterprise path
Want a security packet + guided rollout?
Use the enterprise onboarding flow. We scope one irreversible endpoint, harden it, and produce a rollout plan.