You build the core of this scenario yourself from mechanisms Veriqa already provides; what is still
missing is listed below. We are working on making it simpler to implement in the product.
What it builds on
The scenario needs no new protocol: a sign-in on the work computer gives identity, a QR code on site gives presence. Both steps are ordinary confirmation transactions, which Veriqa already knows how to run. A QR code can sit on several surfaces, and they are not equally hard:What does not exist today
Neither a printer nor a screen is a Veriqa channel, and the reason is not a missing adapter. The channel model has no category of a “place channel” at all: every existing channel is tied to a person — Telegram, WhatsApp, other channels and Email answer “who”, not “where”. Such a category is a change to the channel model rather than one more adapter, and it is common to every surface in the table above.Where its limits are
- Against a colleague in the same room the place factor does not protect at all — they are already inside. The factor is exactly as strong as the control over physical access.
- Printing adds risks of its own. A sheet outlives the session, it can be forgotten in a shared tray, and a personalized onboarding sheet is a long-lived linking secret that a short lifetime does not cure. Without one-time tokens and the invalidation of the remaining QR codes on first use, such a scenario is not safe.
- A QR code on a permanent screen is visible to everyone in the room and to cameras. It can therefore only ever be a marker of place and never a secret: short lifetime, rotation, and possession of it alone grants nothing.
A separate upside unrelated to security: where policy forbids radio, and Bluetooth and Wi-Fi are
switched off, a whole class of competing proximity factors is unavailable — cross-device passkeys
confirm device proximity precisely over BLE. A paper or on-screen QR code needs no radio at all.