Skip to main content
Обычная регистрация просит всё сразу: имя, почту, телефон — до того, как человек понял, нужен ли ему сервис. Половина полей заполняется мусором, а верифицированы они не были никогда. Постепенное обогащение профиля (progressive claim enrichment) переворачивает порядок: пользователь входит одним действием, а недостающие данные приложение получает позже — в момент, когда они действительно понадобились, и сразу верифицированными везде, где за них может поручиться канал.

​
Два способа получить недостающий claim

Внутри входа. Каталог Veriqa:ScopesClaims задаёт каждому claim уровень: Required — вход без него не завершается; Optional — пользователя спрашивают, и он может пропустить; IfAvailable — выдаётся, только если его уже дал канал или он есть в хранилище собранных claims. Приложение поднимает уровень для себя через ClaimLevels своей записи клиента, запрос — параметром claims. Чего не дал канал, Veriqa добирает до выдачи токенов, в той же транзакции: телефон — запросом в канале (Номер телефона), email — кодом, ссылкой или письмом от пользователя (ClaimCompletionEmailMethods записи клиента), поле каталога с Completion — своей формой. Новым authorize-запросом. Когда потребность возникает позже, приложение запускает ещё один вход с теми scope, которые теперь нужны:
  1. Первый вход — минимальный набор: sub и то, что даёт канал по scope=profile. Учётная запись уже создана, пользоваться сервисом можно.
  2. Понадобился контакт — перед действием, которому он нужен, приложение запускает новый authorize-запрос с scope=email или phone. Пользователь подтверждает в мессенджере, и claim приезжает в id_token.
  3. Понадобился канал для уведомлений — тот же приём со scope=channel: см. привязку канала.
В обоих случаях отдельной транзакции обогащения и отдельного API нет: каждый шаг — обычный вход с нужными scope и уровнями.

​
Почему данные верифицированы

Разница с анкетой в том, кто источник значения. Адрес, введённый в форму, — утверждение пользователя; адрес, приехавший claim-ом с канала Email, — следствие того, что человек подтвердил вход именно из этого ящика. Проверять его отдельным письмом уже не нужно. То же с тем, что добирает Veriqa: номер, переданный в канале, и адрес, подтверждённый кодом, приезжают с phone_number_verified / email_verified, а поле формы — это то, что пользователь ввёл.
Состав claims канала зависит от канала, а не от вашего запроса: Telegram не отдаёт email и не отдаст, сколько scope ни проси. Чего канал не даёт, Veriqa может добрать внутри входа — но только phone_number, email и claims каталога с Completion; любой другой claim может быть только IfAvailable. Каталог каналов перечисляет, что даёт каждый: Поддерживаемые каналы.

​
Хороший момент для обогащения

Удобнее всего достраивать профиль там, где пользователь и так подтверждает действие: перед платежом, сменой реквизитов, выдачей доступа. Подтверждение и сбор данных сливаются в одно действие вместо двух — подробнее в step-up.

​
Запоминание собранного

По умолчанию после входа Veriqa не хранит ничего: каждый вход начинается с того, что даёт канал, а собранное Veriqa живёт столько же, сколько транзакция. Поэтому Optional claim спрашивается при каждом входе — пользователь, пропустивший его вчера, сегодня видит вопрос снова. Это меняет опция — хранилище собранных claims. С ним Veriqa помнит по sub, что собрала сама и от каких Optional claims пользователь отказался, и спрашивает только то, чего ещё нет. Отклонённый Optional claim больше не спрашивается, пока его уровень не поднимут до Required. Сохранённое значение при каждом входе проверяется по действующим правилам: значение, не проходящее ужесточённое правило поля, и адрес, полученный способом, который текущее приложение не допускает, собираются заново. Что знать до включения:
  • Записи ведутся по sub, а у одного человека в каждом канале свой sub. Пользователя, вошедшего через Telegram, а потом через WhatsApp, во втором канале спросят снова: связывания учётных записей между каналами Veriqa не делает.
  • Это запись о собранном, а не копия вашего профиля. Veriqa её не редактирует и не синхронизирует с вашим приложением. Токен со значением из хранилища несёт и updated_at — самое позднее время, когда Veriqa собрала значение, которое есть в токене, в секундах от эпохи. Если пользователь с тех пор поменял данные у вас, оставьте ваши: не перезаписывайте профиль из токена при каждом входе, сравнивайте updated_at со временем своего изменения.
  • Хранилище общее для всех приложений тенанта — и удаление тоже.
Удаление записей пользователя — по вашему запросу или после срока без входов — описано в Хранилищах.

​
Что остаётся на вашей стороне

  • решение, какие данные нужны и когда — уровни в каталоге и в запросе; другой модели профиля Veriqa не знает;
  • ваш профиль — claim, приехавший в токене, дальше ваши данные. Хранилище собранных claims, если вы его включили, держит только собранное Veriqa, чтобы не спрашивать повторно, — это не каталог пользователей;
  • политика повторного запроса — сколько живёт полученное значение в вашем приложении и когда спрашивать снова, определяете вы;
  • стирание — когда пользователь удаляет аккаунт, удалите и его записи из хранилища собранных claims: иначе Veriqa об удалении не узнает.