Skip to main content
Helio is a runnable emulator of a whole product rather than of one mechanism: the support section of a fictional company’s website. It strings together what an ordinary web product does — a page anyone can read, sign-in, the person’s data, and a confirmation before an action that matters — so the flows can be seen end to end the way a customer encounters them. samples/dotnet/showcase/support-desk · https://localhost:7360
The support page belongs to the fictional company. The sign-in page and the confirmation window are Veriqa’s own screens, shown as they are: AuthPageDesign sets only the brand name, the logo, the primary color and shows the QR code only on a desktop.

What the customer sees

1

A public page

The support section is readable by anyone; nobody is redirected on arrival.
2

Sign-in

The visitor is sent to the Veriqa sign-in page and comes back signed in: with a QR code on a desktop, with the channel button on a phone. The sign-in asks for no contact.
3

The customer's card

The card is built from the claims the channel provides: display name, first and last name, picture, @username and a masked user id (Telegram). A phone or an address appears only once the customer has confirmed it. Next to it are the customer’s tickets.
4

A contact when a feature needs it

“Call me back” and “Answer by e-mail” open once the customer confirms a phone number or an email address — each by one more authorize request. The request adds the scope and names the claim as essential in the claims parameter, and the application accepts the value only with its *_verified mark. See Progressive claim enrichment.
5

Step-up

Closing or deleting a ticket is confirmed in the channel, by that person. The dialog on the page only guards against a misclick; the question in the channel is the one that decides.
The two flows leave different receipts in the chat. A sign-in’s question is replaced by “Sign-in to Helio Support confirmed ✅” (ReplacePrompt); a ticket action keeps its question and gets the receipt as a message of its own (NewMessage, set in the backend client’s entry), so what was confirmed stays readable. See OutcomeNotice in Configuration.

How it is built

One process plays three roles: Step-up addressed to the signed-in person. Closing and deleting a ticket are two declared action types, resolve-ticket and delete-ticket, each with its own wording. Every confirmation names one expected identity — the identity from the channel the current session came through (expected_identities) — and the operation is applied only when matched_type agrees: a confirmation from another account leaves the ticket untouched, as do a decline and an expiry. The server remembers which ticket a transaction acts on, so no browser can delete one ticket by confirming another. Identifiers stay on the server. The full channel user id addresses the step-up and is never sent to the browser: the user id and the phone number are masked before they are put into a response. No database. The tickets are synthesized from the sub claim, so the same person sees the same list on every visit. Only the tickets the customer has closed or deleted are kept in memory; a restart forgets them.
This step-up goes through the server-to-server confirmation API. The other route — a repeat authorize and an auth_time check in the browser — is described in Second factor, step-up and action approvals.

Running it

Prerequisites:
  • .NET SDK 10.0+;
  • a trusted development certificate — the application calls itself over HTTPS: dotnet dev-certs https --trust;
  • credentials for at least one channel. A Telegram bot token from @BotFather is the shortest path.
Channels ship disabled with empty credentials: a channel switched on without its credentials stops the application from starting. Switch on the ones you have and start the sample:
Open https://localhost:7360. The sample wires the Telegram, WhatsApp and Email adapters; WhatsApp and Email are switched on the same way, through their sections Veriqa:Channels:WhatsApp:* and Veriqa:Channels:Email:* with Enabled set to true. The sign-in page offers exactly the channels that are on — an empty sign-in page means none is enabled. Credentials for each channel are described in Channel setup.
A Telegram bot delivers its updates to one webhook address, so with one bot token only one of the two showcase samples can take sign-ins at a time.
The sample also runs behind an HTTP tunnel, with Telegram switched to Webhook mode. The variables to set, the API of the page and the details of the step-up are in the sample’s README.md in the repository (veriqa.app/source, path samples/dotnet/showcase/support-desk) — it remains the detailed setup guide.

Videos

Sign-in on a desktop

Sign-in by QR and the customer card built from the channel claims.

Sign-in on a phone

No QR code — the channel button opens the messenger on the same device.

Step-up on a desktop

Deleting a ticket takes a confirmation in the messenger.

Step-up on a phone

Closing a ticket is confirmed in Telegram on the same device.

See also