Topological Virtual Authenticator (PBANCHOR)

Nothing described on this page is implemented. PBANCHOR is patent application 19/576,127, a continuation-in-part of 19/553,357 filed on 24 March 2026 and pending USPTO examination. There is no browser extension, no WebAssembly braiding processor and no kinematic-temporal gate anywhere in this build.

The design, in one sentence: a Manifest V3 browser extension that presents itself to relying parties as an ordinary FIDO2 authenticator, deriving its attestation credential from braid group operations rather than from a hardware secure element.

What ships instead. For passkeys, PasskeyBridge runs a hosted WebAuthn relying party with a fixed set of registered origins: Passkeys. For hardware-anchored device checks, the shipped mechanism is the three-channel verifier in Provenance Guard, which runs server-side against enrolled devices instead of inside a browser extension. For post-quantum signatures that exist today, see Security and cryptography.

The rest of this page records what the application claims, so that a reader who meets the name elsewhere can tell the claims apart from the product.

The claimed component is a WebAssembly module that encodes attestation data as braid group generators and computes an AnchorHash by evaluating the Jones polynomial at a primitive root of unity. The security argument is that evaluating that polynomial for an arbitrary braid is #P-hard, so verification stays cheap while forgery does not.

No such module exists in this repository: there is no WebAssembly artifact, no braid code and no AnchorHash. An earlier version of this page quoted a module size; that figure described a design target and has been removed.

What the platform actually uses for quantum-resistant attestation is hybrid signing: ML-DSA-65 under FIPS 204 alongside a classical ES256 or ES384 signature, applied to credentials, chain checkpoints, entropy receipts and boundary proofs.

The claimed gate validates the authenticator's position and time against predicted LEO satellite Doppler telemetry, and collapses ephemeral key material when the observation drifts outside tolerance. None of it is built: no client collects Doppler telemetry, and no memory-zeroing protocol exists.

SGP4 propagation and line-of-sight Doppler do run on the platform, in exactly one module, _shared/tle-doppler.ts, shared by the Provenance Guard kinematic channel and the public satellite radar on the marketing site. It compares a device-reported Doppler shift against a value the server computes from a Starlink TLE catalog that refreshes every four hours, and it refuses catalog rows older than 24 hours. That comparison runs server-side, and only for tenants whose hardening flag is switched on: Provenance Guard.

The design encodes the AnchorHash and an ML-DSA-65 signature into a CBOR attestation object so relying parties see an ordinary packed statement, with the extension intercepting navigator.credentials.create() and navigator.credentials.get(). Two further claims travel with it: purpose-bound ephemeral decryption, where plaintext PII exists only within a single function call, and Braid Grafting, which would carry identity across a device change by entangling the old and new braids.

None of that is implemented. What is implemented, and what a relying party can use today:

• A hosted WebAuthn relying party with registration and authentication endpoints and a fixed origin allowlist: Passkeys.
• Encrypted-at-rest PII with a purpose code logged on every decryption: PII vault. The purpose policies recorded in the dashboard are governance records and are not enforced at decryption time.
• Device succession, at the level of one recorded token: Recursive entropy chaining.

This page describes filed claims. The linked guides describe what runs.