Buyer FAQ for PresenceBound™ / PBI
Straight answers for security, engineering, and procurement. Search the FAQ, jump by category, or go directly to Trust/Status/Docs.
OverviewWhat is Presence-Bound Identity (PBI)?
Presence-Bound Identity (PBI) is a strict trust primitive for irreversible actions. It binds a single-use challenge to an actionHash (or artifact hash), requires a live WebAuthn UP+UV ceremony, and emits a durable receiptHash as cryptographic evidence.
In practice: it turns “approved” from a database claim into something you can verify later.
OverviewWhat problem does PBI solve?
Most systems verify a session once, then assume every subsequent action is legitimate. That’s why stolen tokens, delegated approvals, automation, and mutable logs create catastrophic failures.
PBI hardens the exact endpoints that can’t be undone (money movement, admin changes, deploys, governance): challenge → UP+UV → receipt → enforce only on PBI_VERIFIED.
IntegrationDoes PBI replace SSO / OAuth / IAM?
No. PBI is not a replacement for identity. You keep your existing authentication (SSO/OAuth/JWT/roles). PBI is a presence-gate you apply only where you need proof that a human was physically present for a specific irreversible operation.
Typical pattern: your app authenticates normally, then requires PBI only for high-risk actions.
IntegrationWhat is actionHash and how do we compute it safely?
actionHash is a deterministic hash of the exact operation you’re about to execute (transfer, rotate keys, change role, deploy). The key is canonicalization: the same action must hash the same way everywhere.
Best practice: define a canonical JSON payload for each “purpose profile,” serialize deterministically, then hash.
Developer guidance: Developer Hub →
IntegrationWhat devices/authenticators are supported?
PBI uses WebAuthn (passkeys). In practice this includes FaceID/TouchID (platform authenticators) and hardware keys that support user verification. The critical requirement for “presence proof” is that verification enforces UP+UV.
The exact authenticator matrix depends on the browser/OS. PBI verifies the flags and the assertion cryptographically.
SecurityWhat does PBI_VERIFIED guarantee?
PBI_VERIFIED means: a WebAuthn ceremony occurred with User Present + User Verified for a single-use challenge bound to this actionHash within expiry, and the server verified it successfully and minted a receipt.
Your enforcement rule is strict: execute only if decision == PBI_VERIFIED.
SecurityHow does PBI prevent replay attacks?
Replay is prevented by construction:
- Single-use challenges (once used, cannot be reused)
- Expiry windows (late approvals are rejected)
- Action binding (a ceremony for one actionHash can’t approve another)
SecurityDoes PBI stop token/session theft from causing catastrophic actions?
It reduces blast radius dramatically. Even if an attacker steals a session token, they still cannot pass an irreversible gate without a live UP+UV ceremony. Session auth proves access; PBI proves presence for the specific action.
SecurityWhat about insiders or admins?
PBI doesn’t “solve human coercion,” but it does change the game for insiders: approvals become provable ceremonies tied to an actionHash and receipt. “An admin did it” becomes “here is the proof, time window, and bound action.”
PrivacyDo you store biometric data?
No. WebAuthn biometrics remain on the device. The server verifies an assertion; it does not receive biometric templates.
PrivacyWhat data is stored by the API?
Typical storage is minimal: challenge metadata (expiry/used), actionHash reference, decision, receiptHash, timestamps, and usage events for billing. You can keep the action payload itself in your system; PBI can operate with hashes + references.
EvidenceWhat is receiptHash and why is it better than logs?
Logs are mutable and often not dispute-ready. A receiptHash is a cryptographic reference to the verification outcome bound to the actionHash and time window. It’s designed to be verifiable later.
EvidenceDo you support offline verification / packs / proofs?
PBI supports optional portable verification artifacts for offline review (air-gapped audit, custody chains). These verify under a trust policy with rotation/revocation/expiry semantics.
See verifier tooling and specs in pbi-stdlib.
OperationsDo you have a Trust Center, Status page, and Changelog?
Yes. These are core enterprise signals and part of the default buyer path:
OperationsDo you support rate limiting and abuse controls?
Yes. Rate limiting is a first-class part of operating verification endpoints safely. The exact policy is deployment-dependent (per key, per IP, burst/steady-state).
LicensingWhat does AGPL mean for our organization?
AGPL is the open-source license path. If you modify the software and run it as a network service, AGPL requires you to provide the source of your modified version to users of that service. Many enterprises choose a commercial license to avoid this obligation.
Not legal advice. Your counsel should confirm your specific scenario.
LicensingWhen do we need a commercial license?
If you want to run PBI in a proprietary SaaS or closed-source product without AGPL obligations, you obtain a commercial license.
Contact: sales@kojib.com →
EnterpriseWhat does an enterprise pilot look like?
Fast path: we pick one irreversible endpoint, define the canonical action payload, integrate the challenge/verify gate, and produce an audit-ready receipt trail. Then we expand coverage endpoint-by-endpoint.
Start here: Enterprise onboarding →
EnterpriseDo you offer support, SLAs, and incident response?
Yes—support and SLA/incident response commitments can be included under enterprise terms. We also provide deployment guidance and environment separation patterns.
Support: support@kojib.com →