Carrier lookup and signed passkey attestations for your fraud engine.
PasskeyBridge looks up live carrier state when your service calls, and signs the passkey session attestation from the WebAuthn assertion. Your fraud engine consumes both.
- Carrier lookup and signed passkey session attestations, each verifiable later.
- Catches credential replay where a device score and OTP both pass.
- Your service calls PasskeyBridge before it calls Sift, Forter, Sardine or Alloy.
- BYOK. Identifiers are stored only as HMAC-SHA-256 digests keyed with a server-held pepper.
The gap in most fraud stacks
Device fingerprinting is a probabilistic score. A carrier lookup taken at signup goes stale. OTP is a challenge to the same channel an attacker already controls. When those three pass and the transaction still results in a chargeback, a common pattern is that the credential and the device both look clean and have just changed hands.
A carrier lookup at request time, plus a signed passkey session attestation, closes that specific gap. The two results are separate records.
What the signal actually contains
The checks are separate records. A passkey session attestation is the WebAuthn assertion, signed. A carrier lookup returns the provider's SIM-swap result, its age in hours, and porting when that provider reports them. DPoP (RFC 9449) binds a token to the key that signed the request. A relying party can require the passkey to be hardware-bound, which refuses a credential that can sync.
Credentials, passkey session attestations, and cascade receipts are dual-signed: a classical ES256 or ES384 JWS plus a detached ML-DSA-65 signature. The detached ML-DSA signature covers the JWS signing input followed by `:qnonce:` and a quantum-seeded nonce that travels with the signature. You can store that record and verify it later with the published keys.
- Edge latency for /health is published live at /developers/playground.
- Server-side flows call the REST endpoint. Passkey enrollment uses WebAuthn in the browser.
- The signed records can be consumed beside a Sift, Forter, Sardine, or Alloy workflow.
Where it fits in the stack
Most fraud teams wire this in as a pre-filter: clean signal skips the heavy async checks, ambiguous signal fans out to the existing engine, hard-fail signal blocks before the KYC or IDV credit is burned. The design goal is a meaningful cut in vendor spend on the clean-traffic path plus a lower p95 decision latency; the exact lift depends on baseline traffic mix and current vendor cost.
It is also usable inside recovery flows and high-value transaction gates as a standalone step, where the carrier-state check catches the overnight SIM-swap window that batch data pipelines miss entirely.
The PasskeyBridge approach
Signed passkey attestation
A passkey session attestation is a signed record your rules engine can verify with the published keys. The carrier lookup is a separate response.
See the OpenAPI spec →Carrier state, live
Every call checks the live SIM swap state, its age in hours, and porting on the carrier line tied to the account at call time. A recycled number reaches the platform as a signal type that a tenant posts.
Carrier signal architecture →Replayable audit trail
Credentials and passkey session attestations are signed with classical ES256 or ES384 plus a detached ML-DSA-65 signature. The detached ML-DSA signature covers the JWS signing input followed by `:qnonce:` and a quantum-seeded nonce that travels with the signature. Store the record and verify it later with the published keys.
Post-quantum posture →How PasskeyBridge works with your fraud engine
PasskeyBridge returns the carrier lookup and, when a passkey is asserted, a signed session attestation. Your existing fraud engine (Sift, Forter, Sardine, Alloy, or an in-house model) consumes those records alongside everything else it looks at, and keeps session scoring, chargeback learning and the fraud decision.
Frequently asked
- How do we integrate this without ripping out Sift/Forter/Sardine/Alloy?
- You add the carrier lookup, and the passkey session attestation where a passkey is asserted, in front of the existing decision step. You can start with specific flows, such as recovery flows or high-value transactions, then expand to login and checkout once the operational data proves out.
- What does 'zero PII stored' actually mean in practice?
- Phone numbers, email and IP addresses, and subject identifiers are hashed at the edge with keyed HMAC-SHA-256 under a server-held pepper before they touch storage. Cross-signal matching still works because the digest is deterministic; reading a stored identifier back to a person is not possible, because the pepper never leaves our servers.
- How does it hold up against agent and bot impersonation?
- LLM-driven session automation still has to produce a passkey assertion from the authenticator the user holds. A relying party that requires a hardware-bound passkey refuses a credential that can sync. Combined with the carrier-line binding, agent-driven onboarding and takeover attempts fail before they reach your IDV vendor.
- Is the signal available in server-to-server flows without a browser?
- The carrier lookup and the ingest call are server-to-server. A fresh passkey assertion still has to come from the authenticator on the user's device, through WebAuthn. There is no separate browser helper package.
- How is this different from a device fingerprinting SDK?
- A device fingerprint is a probabilistic identifier. This is a cryptographic proof-of-possession plus a live carrier-state check, signed as evidence. A device fingerprint estimates whether this is the same device as last time. PasskeyBridge checks that the device holds a specific passkey at request time and that its carrier binding has not moved. A relying party can require that passkey to be hardware-bound.
Guides for this
Talk to us
One reply gets you a 2-page architecture brief and a real latency probe against production.