Перейти к основному содержанию
Все привычные факторы входа привязаны к человеку или к его устройству и ни один не отвечает на вопрос «а человек вообще здесь?». Место отвечает. Зачем это нужно и кому, рассказано на странице «Место и личность».
Механизмы для этого сценария в Veriqa уже есть, логику поверх них вы реализуете на своей стороне так, как удобно вам, — см. «Что вы реализуете сами». Мы работаем над тем, чтобы упростить его реализацию в продукте.

​
Из чего собирается сценарий

Сценарий не нуждается в новом протоколе: вход на рабочем компьютере даёт личность, QR-код на месте — присутствие. Оба шага — обычные транзакции подтверждения, которые Veriqa уже умеет вести. Поверхностей для QR-кода несколько, и они не равны по трудности:

​
Что вы реализуете сами

Принтер и экран не каналы Veriqa: каналы привязаны к личности и отвечают на вопрос «кто», а не «где». Поэтому QR-код места выводит ваш сервер, и оба шага ведёт он:
  • Личность. Человек входит на рабочем компьютере обычным authorize-запросом, и приложение получает его sub, а в amr — канал, в котором он подтвердил вход.
  • QR-код места. Для проверки присутствия сервер создаёт транзакцию серверного подтверждения POST /api/transaction/confirmation с типом действия, в сообщении которого названо помещение, и выводит на поверхность картинку channel_entry.qr из ответа. allowed_channel_types сужает транзакцию до канала, в котором человек вошёл.
  • Сверка с вошедшим. Человек сканирует код и подтверждает в мессенджере, сервер дожидается confirmed в GET /api/transaction/{id}/result. Точка входа в QR-коде действует на предъявителя, поэтому присутствие засчитывается только после сверки: передайте при создании expected_identities и проверьте matched_type либо обменяйте транзакцию на id_token и сравните sub с тем, кто вошёл на компьютере.
  • Короткий срок и ротация. ttl_seconds задаёт время жизни транзакции, от 60 до 1800 секунд. Транзакция подтверждается один раз, поэтому после подтверждения или с наступлением response_valid_until сервер выводит новый QR-код.

​
На что обратить внимание

  • Против коллеги в той же комнате фактор места не защищает вовсе — тот и так внутри помещения. Сила фактора ровно равна силе контроля физического доступа.
  • Печать добавляет свои риски. Лист живёт дольше сессии, его можно забыть в общем лотке, а персонализированный онбординг-лист — долгоживущий секрет привязки, который не лечится коротким сроком жизни. Без одноразовости токена и гашения остальных QR-кодов при первом использовании такой сценарий небезопасен.
  • QR-код на постоянном экране виден всем в помещении и камерам. Поэтому он может быть только маркером места и никогда — секретом: короткий срок жизни, ротация, и само обладание им не даёт ничего.
Отдельный плюс, не связанный с безопасностью: там, где политика запрещает радио и выключены Bluetooth и Wi-Fi, недоступен целый класс конкурирующих факторов близости — кросс-девайсные passkeys подтверждают близость устройств именно через BLE. Бумажному или экранному QR-коду радио не требуется вовсе.