Skip to main content
This page is the plan for the next release. Until it ships, none of this is in the current packages: what works today is in Supported channels and Limitations.

​
Five new channels — 8+ in total

Viber, LINE, Messenger, Instagram Direct and Slack are already in testing and ship in the next release. Viber and LINE open markets of their own, Messenger and Instagram run on the Meta platform the WhatsApp adapter already uses, and Slack brings sign-in and step-up into the workplace. For you as an integrator nothing changes: a new channel is switched on in configuration, and your application keeps receiving ordinary OpenID Connect tokens. What each channel adds to the claims, and whether the user has to send a message — on the Supported channels page. One thing to know in advance: Slack links cannot pre-fill a message, so there the user types the code shown on screen. Today the QR code carries the channel’s deep link itself. That link is long, and a long link means a dense QR code: it is harder for a phone camera to read, and it limits how the pre-filled message can be worded. In hop mode the QR code carries a short one-time link to your Veriqa server instead. The phone opens it, and the server sends the user on to the messenger. That extra step buys:
  • a lighter QR code — its density no longer depends on the length of the channel link;
  • an early “scanned” signal — the page on the desktop learns that the phone has opened the link before the confirmation arrives, and can tell the user to continue on the phone;
  • the context of the scanning device — time, IP, browser, OS and device type are recorded next to the initiator context as risk signals, not as an authentication factor;
  • a launch page on the phone where a direct jump into the messenger app is unreliable.
The destination is always derived by the server from the transaction, never taken from the link: hop mode is not a URL shortener and cannot be turned into an open redirect. It is off by default and is switched on for the whole server or per channel — for example, only for WhatsApp.

​
Channel restriction policies

Anyone with a messenger can confirm a transaction. Restriction policies narrow that circle by what the channel reports about the person confirming:
  • sign-in only from corporate email domains;
  • only phone numbers from the countries you name;
  • only users whose channel provides a phone number.
Rules are set per channel in configuration, with no code. A confirmation that fails them is declined with a neutral message that does not reveal which rule fired; the details go to the audit trail. The transaction itself stays alive — the user can confirm from a channel that passes. Policies are off by default. The boundary is worth stating: this is a filter over what the channel reports, not a cryptographic barrier. A phone country code is the prefix of the number, not the person’s location, and a rule can only check what the channel actually provides — which claims each one gives is listed on Supported channels.