The network-effect hypothesis
One authentication.
More than one client.
Can a recent authentication at one client reduce the next client’s need for Mobile Auth?
Visit a shared Prove origin once. Prove possession of its saved key. Reuse an eligible event, then return with a result intended for this client.
Simulation, not Prove authentication. Browser keys, signatures and server checks are real. Mobile Auth and identities are simulated. No phone number or carrier call is used.
Your current client
Client
The first visit takes you to the shared origin as a full page. There is no iframe permission prompt in this flow.
At the shared origin, explicitly confirm the named client. Returning clients can prove possession locally while the server checks the same authentication event.
Measured result
Start with Client B.
Complete one simulated Mobile Auth. Then open C in this same browser and see whether that event can be reused.
Server receipt
No completed check yet.
Separate the two questions
A key hit is not an authentication hit.
Key possession: can this browser sign a fresh, one-time challenge with a registered key? A key stored yesterday may still work today.
Authentication reuse: is the original Mobile Auth event recent enough, is the key active, and does this client accept reuse? A stale event requires fresh authentication even when the key works.
The network key stays at the shared origin. Each client gets a different identifier and its own linked key, never another client’s private key or identifier. The server can correlate those bindings; this is not anonymous authentication.
Pressure-test it yourself.
- Cold start: use a fresh browser profile, open B and complete the simulated Mobile Auth step. Expect one call.
- Cross-client reuse: open C within five minutes. Expect a network-key hit and zero Mobile Auth calls after confirming C.
- Client return: run another check on C. Expect zero calls and no redirect while the event remains eligible.
- Freshness: select “Require fresh” or wait more than 15 seconds and select the short policy. Expect a key hit but another simulated call. Reuse does not extend the original event.
- Revocation: check “Visit the shared origin,” then open key controls there and revoke. Return and retry: the client key must no longer authorize reuse.
- Storage loss: delete only the client key below to test recovery through the network key. Delete the network key at the shared origin to test a cold start there. Browser deletion is distinct from revocation: a still-valid client binding can continue until its policy or lifecycle expires.
Only this experiment’s key is deleted. Existing iframe-test keys are unaffected.
This tab’s observations
| Time | Path | Key hit | Mobile Auth calls |
|---|
Sensitivity model · editable assumptions
More keys help only when events are reusable.
Model eligible reuse as coverage × ability to reach and complete the key flow × fresh-event share × policy acceptance. These are conditional assumptions, not measurements from this demo. Costs are illustrative US dollars per completed check.
This simple model excludes acquisition, support, fraud losses and lost conversions. Track those before claiming savings. “Zero Mobile Auth calls” does not mean zero cost.
What this can—and cannot—establish.
This lab can demonstrate key persistence across client navigation, fresh signatures, one-time code redemption, recent-event reuse and revocation. A successful run cannot establish a population hit rate, months of browser retention, real carrier assurance, or production unit economics.
A dedicated origin such as auth.prove.com is the proposed production home. This lab uses prove-key-frame.pages.dev as its stand-in. Keys are origin-scoped; moving hosts later requires enrollment again. Client B uses pages.dev and Client C uses workers.dev. Visiting this authentication page is intentional; silent bounce redirects are not the foundation of the design.
Safari, Firefox, mobile browsers, private mode and long gaps between visits need separate longitudinal measurement. A browser key proves possession of browser state, not the presence of a particular human. Native apps and separate browser profiles do not automatically share it.