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

# Постепенное обогащение профиля

> Progressive claim enrichment: приложение достраивает профиль пользователя по мере надобности, получая верифицированные данные в момент подтверждения, а не анкетой на входе.

Обычная регистрация просит всё сразу: имя, почту, телефон — до того, как человек понял, нужен ли
ему сервис. Половина полей заполняется мусором, а верифицированы они не были никогда.

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

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

**Внутри входа.** Каталог [`Veriqa:ScopesClaims`](/docs/ru/reference/configuration#veriqascopesclaims)
задаёт каждому claim уровень: `Required` — вход без него не завершается; `Optional` — пользователя
спрашивают, и он может пропустить; `IfAvailable` — выдаётся, только если его уже дал канал или он
есть в хранилище собранных claims. Приложение поднимает уровень для себя через `ClaimLevels` своей
записи клиента, запрос — [параметром `claims`](/docs/ru/reference/oidc-capabilities). Чего не дал канал,
Veriqa добирает до выдачи токенов, в той же транзакции: телефон — запросом в канале
([Номер телефона](/docs/ru/guides/phone-number)), email — кодом, ссылкой или письмом от пользователя
(`ClaimCompletionEmailMethods` [записи клиента](/docs/ru/reference/configuration#clients)), поле
каталога с `Completion` — своей формой.

**Новым authorize-запросом.** Когда потребность возникает позже, приложение запускает ещё один вход
с теми scope, которые теперь нужны:

1. **Первый вход** — минимальный набор: `sub` и то, что даёт канал по `scope=profile`. Учётная
   запись уже создана, пользоваться сервисом можно.
2. **Понадобился контакт** — перед действием, которому он нужен, приложение запускает новый
   authorize-запрос с `scope=email` или `phone`. Пользователь подтверждает в мессенджере, и claim
   приезжает в `id_token`.
3. **Понадобился канал для уведомлений** — тот же приём со `scope=channel`: см.
   [привязку канала](/docs/ru/scenarios/channel-linking).

В обоих случаях отдельной транзакции обогащения и отдельного API нет: каждый шаг — обычный вход с
нужными scope и уровнями.

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

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

<Warning>
  Состав claims **канала** зависит от канала, а не от вашего запроса: Telegram не отдаёт email и не
  отдаст, сколько scope ни проси. Чего канал не даёт, Veriqa может добрать внутри входа — но только
  `phone_number`, `email` и claims каталога с `Completion`; любой другой claim может быть только
  `IfAvailable`. Каталог каналов перечисляет, что даёт каждый:
  [Поддерживаемые каналы](/docs/ru/guides/supported-channels).
</Warning>

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

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

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

По умолчанию после входа Veriqa не хранит ничего: каждый вход начинается с того, что даёт канал, а
собранное Veriqa живёт столько же, сколько транзакция. **Поэтому `Optional` claim спрашивается при
каждом входе** — пользователь, пропустивший его вчера, сегодня видит вопрос снова.

Это меняет опция — [хранилище собранных claims](/docs/ru/guides/storage#хранилище-собранных-claims). С
ним Veriqa помнит по `sub`, что собрала сама и от каких `Optional` claims пользователь отказался, и
спрашивает только то, чего ещё нет. Отклонённый `Optional` claim больше не спрашивается, пока его
уровень не поднимут до `Required`. Сохранённое значение при каждом входе
проверяется по действующим правилам: значение, не проходящее ужесточённое правило поля, и адрес,
полученный способом, который текущее приложение не допускает, собираются заново.

Что знать до включения:

* **Записи ведутся по `sub`, а у одного человека в каждом канале свой `sub`.** Пользователя,
  вошедшего через Telegram, а потом через WhatsApp, во втором канале спросят снова: связывания
  учётных записей между каналами Veriqa не делает.
* **Это запись о собранном, а не копия вашего профиля.** Veriqa её не редактирует и не
  синхронизирует с вашим приложением. Токен со значением из хранилища несёт и `updated_at` — самое
  позднее время, когда Veriqa собрала значение, которое есть в токене, в секундах от эпохи. Если
  пользователь с тех пор поменял данные у вас, оставьте ваши: не перезаписывайте профиль из токена
  при каждом входе, сравнивайте `updated_at` со временем своего изменения.
* **Хранилище общее для всех приложений тенанта** — и удаление тоже.

Удаление записей пользователя — по вашему запросу или после срока без входов — описано в
[Хранилищах](/docs/ru/guides/storage#удаление-по-sub).

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

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


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