Skip to main content
The phone number and the email address reach the application in the phone_number and email claims. Some channels give them on their own; when they are missing, the application gets them in one of two modes:
  • At the first sign-in. Veriqa collects the phone number or email inside the same sign-in, before it issues the tokens. Whether the claim is needed and whether the user may skip it is set by its level in the Veriqa:ScopesClaims catalog — see Collecting extra claims.
  • Later, when needed. The user signs in without any contact details. When the phone number or email is needed, the application starts a new authorize request with scope=phone or scope=email, and the user confirms it in the messenger.
The Helio showcase sample shows the second mode: the sign-in asks for no contact details, and the customer confirms the phone number and email later, each with a request of its own.

​
At the first sign-in

​
Phone number

Veriqa asks the user for the number in the channel itself. How this works in each channel, and whether ownership of the number is proven, is covered in Phone number.

​
Email

Veriqa collects the address by an email that confirms it or by an email the user sends. The available methods are set by ClaimCompletionEmailMethods of the client entry. The user sees at most three options, in the order of the list:
  • Confirm via email — the user types the address and presses one button. What arrives is decided by the list, not by the user: a code to enter on the page (Code), a link to a confirmation page (MagicLink), or one email with both (claim-code-link-mail) when the list names both — whichever the user does first confirms the address. email_verified is true;
  • an email the user sends (Push) — on the device that confirmed the sign-in; email_verified is true;
  • without confirmation (Unverified) — the address is only typed; email_verified is false.
A value typed into the other fields of the form survives every step of the email flow — requesting the email, entering the code, switching the method. “Continue” is always there: pressed before the address is confirmed, it saves the fields and the page says “Confirm the address to continue.” Pressed with a code or an address typed into the email block, it does what that input is for instead — checks the code, sends the email, or saves the address without confirmation — and leaves the other fields as typed. Another email cannot be requested sooner than Veriqa:Channels:Email:MailResendInterval after the previous one — see Sending an email again. What the email block shows as the user proceeds:
  • After the email is sent, the code field and Send again. “Send again” sends nothing by itself: it brings back the address field, filled with the address of the last email, so the user either sends the same email once more or corrects the address first.
  • A code whose attempts are spent turns the block back to that address field while emails are left within the limits; when none are left, the block says “The code has no attempts left.” and asks for nothing more. When the per-address limit is reached, the block says “Too many emails have been sent to this address. Try again later or enter another address.”
  • An address confirmed by the link in the email — opened on a phone, say — reaches, on its own, the form on the device the sign-in started on: the form continues as if “I have confirmed the address” were pressed, keeping what the user typed into the other fields. A page that fell back to polling keeps the button for that.
  • A recorded address stays in the block while other fields of the form are still open: “The address … is confirmed”, or “The address … is saved” for an address taken without confirmation.
The page the link in the email opens offers Cancel beside “Confirm the address”, and Close once the address is confirmed; both only close the tab.

​
Later, when needed

The first sign-in takes the minimum: sub plus whatever the channel gives. Before the action that needs a contact, the application starts a new authorize request with scope=phone or scope=email. The user confirms it in the messenger, and the claim arrives in the id_token. The sample page describes how Helio does it; the general scheme is in Collecting extra claims.

​
Why the data is verified

The difference from a form is who the source of the value is. An address typed into a form is the user’s word; an address that arrives as a claim from the Email channel follows from the person having confirmed a sign-in from that very mailbox. There is nothing left to verify with a separate email. The same holds for what Veriqa collects: a number shared in the channel and an address confirmed by a code come with phone_number_verified / email_verified, while a form field is what the user typed.