Skip to main content
A conventional registration asks for everything at once — name, email, phone — before the person has decided whether they want the service at all. Half the fields get filled with noise, and none of them were ever verified. Progressive claim enrichment inverts the order: the user signs in with a single action, and the missing data arrives later — at the moment it is actually needed, and already verified wherever the channel can vouch for it.

​
Two modes: at the first sign-in or later

The application gets a missing claim in one of two modes: at the first sign-in, where Veriqa collects it inside the same sign-in, or later, when it is needed, with a new authorize request. The Nova Stream showcase sample shows the first mode, and the Helio showcase sample the second. At the first sign-in. The Veriqa:ScopesClaims catalog gives each claim a level: Required — the sign-in does not complete without it; Optional — the user is asked and may skip it; IfAvailable — issued only when the channel or the collected claims store already has it. An application raises a level for itself with ClaimLevels of its client entry, and a request raises it with the claims parameter. What the channel did not give, Veriqa collects before it issues the tokens, in the same transaction: the phone number through a request in the channel (Phone number), the email address through an email that confirms it or an email the user sends (ClaimCompletionEmailMethods of the client entry), and a field of the catalog that has Completion on a form of its own — a text, a date or a choice from a list (Format: Choice). Nova Stream collects a date of birth and a favorite genre this way. How Veriqa collects the phone number and email is covered in Getting the phone number and email. Later, when needed. The application starts one more sign-in with the scopes it now needs:
  1. First sign-in — the minimum: sub plus whatever the channel gives under scope=profile. The account exists and the service is usable.
  2. A contact is needed — before the action that needs it, the application starts a new authorize request with scope=email or phone. The user confirms in the messaging app and the claim arrives in the id_token.
  3. A notification channel is needed — the same move with scope=channel: see channel linking.
Helio confirms a phone number and an email this way, each with its own request. Either way there is no separate enrichment transaction and no separate API: every step is an ordinary sign-in with the scopes and levels you need.

​
What can be collected

Which claims the channel gives depends on the channel, not on your request: Telegram does not provide an email and never will, however many scopes you ask for. What the channel does not give, Veriqa can collect inside the sign-in — but only phone_number, email and the catalog claims with Completion; any other claim can only be IfAvailable. The catalog lists what each channel gives: Supported channels.

​
The right moment to enrich

The easiest place to fill in a profile is where the user is confirming something anyway: before a payment, a change of payment details, granting access. The confirmation and the data collection merge into one action instead of two — see step-up.

​
Remembering what was collected

By default Veriqa keeps nothing after the sign-in: every sign-in starts from what the channel gives, and what Veriqa collected lives only as long as the transaction. An Optional claim is then asked for at every sign-in — the user who skipped it yesterday sees the question again today. The collected claims store is an option that changes this. With it Veriqa remembers by sub what it collected itself, and which Optional claims the user declined, and asks only for what is still missing. A declined Optional claim is not asked for again until its level is raised to Required. A stored value is checked against the current rules on every sign-in: a value that no longer passes a tightened field rule, or an address obtained in a way the current application does not allow, is asked for again. What to know before turning it on:
  • Records follow the sub, and one person has a different sub in every channel. A user who signs in through Telegram and then through WhatsApp is asked again in the second channel: Veriqa does not link accounts across channels.
  • It is a record of what was collected, not a copy of your profile. Veriqa does not edit it and does not synchronize it with your application. A token with a stored value in it also has updated_at — the latest time Veriqa collected a value the token carries, in seconds since the epoch. If the user has changed the data on your side since then, keep yours: do not overwrite your profile from the token at every sign-in, compare updated_at with the time of your own change.
  • It is shared by all applications of a tenant, and so is a deletion.
Deleting the records of a user — at your request or after a period without sign-ins — is described in Storage.

​
What stays on your side

  • deciding what data you need and when — the levels in the catalog and in the request; Veriqa has no profile model beyond them;
  • your profile — a claim that arrives in the token is your data from then on. The collected claims store, when you turn it on, keeps only what Veriqa collected, to avoid asking again — it is not a user directory;
  • the re-ask policy — how long a received value stays valid in your application and when to ask again is yours to define;
  • erasure — when a user deletes their account, delete their records from the collected claims store as well; Veriqa does not know about the deletion otherwise.