You build the core of this scenario yourself from mechanisms Veriqa already provides; what is still
missing is listed below. We are working on making it simpler to implement in the product.
What Veriqa stores today
Start with the current state, because that is what you make a risk decision on. The channel identifier and the profile are stored in the clear. The key of a channel identity is the pair “channel type + user identifier within it”, and the profile sits next to it: display name, first and last name, username, email address, phone number, avatar, locale. There are no derived forms along the storage path, and the record has no lifetime either. This is exactly the behavior any connector has — but it is better to know it in advance. Masking today covers the journals only. By contract the audit trail and the logs write neither tokens nor unmasked identities, and that works. The rule does not touch the main store. And a qualification the risk decision turns on: out of the box that store does not exist. Veriqa ships no implementation of the port that would persist a channel identity and registers none, so a stock installation keeps the profile only for the minutes the transaction lives. Everything described above starts applying the moment you register an implementation of your own. The full inventory — what is kept where, for how long, and what is encrypted — is in Security and data handling.The encryption the product already has applies to channel provider secrets, not to user
identifiers. The Preparing for production checklist covers secrets and the database connection — not identifiers.
How the mode is designed
The mode is designed as the integrator’s decision — a tenant-level mode switched on deliberately, not a default that changes behavior for everyone. It comes down to four properties, and they are connected. A derived value instead of the native identifier. The record holds a one-way hash keyed with a secret, not the identifier itself. The same person always yields the same value — the account is recognized on every sign-in — but the value does not unwrap back into a Telegram id or an email address. The secret does not live next to the data. It belongs in a KMS or a secret store, self-hosted deployments included, with no concessions. This is not hardening advice but a condition of the scheme working at all: the space of possible inputs is small enough to be enumerated in full, and a secret inside the same snapshot as the database would let an attacker simply recompute the function. Where there is no secret store, the mode is designed not to switch on rather than to degrade into something weaker. Different integrators get different values. The tenant takes part in the computation, so the same person becomes a different value in each integrator’s database. Two leaked databases do not join to each other, and neither joins to a purchased marketing list. And where the scenario allows — no value at all. If the user always arrives from the channel, the identifier comes with every confirmation and there is nothing to keep between transactions. The strongest form of the property is not “well encrypted” but “never written down”.What it costs
Both consequences follow from the property itself rather than qualifying it:- Finding a user by their Telegram id or email address becomes impossible. That is exactly what is being paid for.
- A scenario that pushes a confirmation into the channel itself does need the native identifier back. There it is designed to live encrypted under the same service’s key — reversible, unlike a hash: stronger than storing it in the clear, weaker than a mode that stores nothing.