> ## Documentation Index
> Fetch the complete documentation index at: https://veriqa.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Place and identity

> A presence factor: a QR code that exists only inside the room. What this scenario demands of the channel model and where its limits are.

Every common sign-in factor is tied to a person or to their device, and not one of them answers
the question "is the person actually here?". Place answers it. Why this matters and for whom is covered
on the [Place and identity](https://veriqa.app/whats-next/place-and-identity?lang=en) page. Here is
what it demands of the product.

<Note>
  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.
</Note>

## 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:

| Surface | What it gives | What it costs |
| - | - | - |
| A sheet printed on the office printer | place, plus a way to carry the QR code where there is no screen | consumables, a shared output tray, vendor-specific printing |
| A screen in a shared area (the meeting-room TV) | a large QR code, readable from anywhere in the room | the hardware is already there, but content appears only the way the vendor allows |
| A desk IP phone | place more precisely — a specific desk rather than a corridor | the screen is small: how much data fits into a readable QR code is a question to measure |
| A dedicated mini-panel | no consumables, no shared tray, no vendor-specific printing | it is a hardware purchase |

## 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.

<Note>
  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.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.