Verifying with a national eID

National eID lets a customer prove who they are with their country’s own identity scheme. The customer approves in their own eID app, on their own device, and a completed approval verifies them at high assurance on its own, because the proof comes from the scheme rather than from anything oHallo infers. It is the strongest verification method oHallo offers, and the only one that reaches high-assurance as a single factor (see Assurance levels).

Denmark with MitID verifies customers today. The configuration screen offers Denmark, Norway and Sweden, and each country’s row states plainly whether the method runs for your combination of scheme, broker and level, so the screen itself is the authority on what your workspace can offer.

What it needs

Three things have to be in place before a customer can verify this way:

The eID lookups under Customer records. The approval is addressed from your own customer record, so oHallo has to know where the identifier sits in your system. Designate The eID reference on the record and, where your broker addresses customers by it, A national identity number under Settings, then Customer records. See Finding your customers.
A country scheme with broker credentials, set up on the National eID tab as described below.
National eID switched on for the channel. Email, voice and live chat channels offer the method; you turn it on per channel.

Setting up a country

Open Settings, then Verification, then the National eID tab. Click Add country. One row covers one country: a country is one scheme family at one broker with one client registration, so each country carries its own broker agreement and its own client credentials.

The panel asks for:

Country. Denmark verifies with MitID, Norway and Sweden with BankID.
Broker. The company your eID agreement is with. The list shows the brokers serving that country: Signaturgruppen covers Denmark, while Idura, Signicat, Scrive and ZignSec cover all three countries.
Issuer. The address your broker answers on. Signaturgruppen, Scrive and ZignSec use one issuer address for every customer, so the panel fills it in for you. Idura and Signicat give each customer their own broker domain; enter yours exactly as the broker issued it.
Client ID and Client secret. The credentials from your broker registration. The secret is stored once and stays in place until you replace it; the panel shows whether one is stored rather than the value itself.
Client authentication. How the secret is presented to the broker. Resolved from the broker follows the broker’s published metadata and suits almost every registration; pick a specific method only when your registration names one.
Return address. Shown read only, with a copy button. Register this address at your broker exactly as shown, byte for byte. The broker sends completed verifications back to it, and brokers accept only addresses registered in advance.
Level of assurance. The scheme’s own level, from your broker agreement. Denmark and Norway offer Substantial and High; Swedish BankID runs at a single level. High activates once the scheme has been proven at that level end to end, and until then a verification asking for high is declined.
What customers see in the app. Up to 130 characters, shown in the eID app when the approval arrives. Name yourself the way your customers know you, because this line is how they decide the request is genuine.
Accepted identities (Denmark). Private individuals are always accepted; a checkbox adds business identities (MitID Erhverv).
Enabled. Whether customers verify with this scheme on channels where National eID is switched on.

Save, and the country appears as a row on the tab.

Reading the readiness line

Each country row carries a line that states whether the method runs, derived from your actual configuration rather than from a checklist:

Ready. The app approval runs. Customers of this country can verify with the approval in their app.
Ready. The verification link runs. The link form of the method works for this country.
Blocked, followed by the reason in one sentence, for example “Enter the broker client ID and client secret to activate this country” or “Designate an eID identifier under Customer records first.”

This line is the honest surface for Norway and Sweden: you can enter your broker details for either country today, and the row states when the combination verifies customers, with “This broker, scheme and level combination activates once it has been proven end to end” shown until it does.

Switching it on per channel

On the Channels tab, click Customise on a channel. Under How the customer proves it, tick National eID. The checkbox becomes available once a country with broker credentials is switched on; before that, it points you back at the National eID tab.

The Will a caller be verified? section at the foot of the Channels tab then shows a line per channel, for example “Ready. The customer approves in their national eID app (Denmark).” Read it before you go live.

Delivery on email channels

On an email channel, you choose how a verification reaches the customer. The Delivery on email channels setting on the National eID tab offers two postures:

App approval. The approval goes straight to the customer’s eID app on their own device. The assistant’s reply asks them to approve there, and the scheme keeps the approval open for a few minutes. This suits customers who read your reply as it arrives, with their phone at hand.
Verification link in the reply. The reply carries a link into the customer’s own thread. Everything starts when they click, at their own timing: the scheme login opens, they approve, and they return to the conversation. The link runs per scheme where the broker token carries an identifier oHallo can compare against your record; for other schemes the assistant sends the app approval instead.

On a phone call the approval always goes to the app, because the caller is present on the line. See Verifying on a phone call.

In live chat the verification arrives in the conversation itself: the assistant’s message and a verification bubble with a Verify your identity button arrive together, the button opens the verification page in a new tab, and the completed verification continues the chat automatically. See Live chat and the chat widget for what the visitor sees, including what happens when a button expires.

What your customer experiences

A customer asks about something that touches their data, such as the status of an order. The assistant finds the matching record in your own system, and the approval appears in that person’s eID app, showing the message you configured and the provider name. They approve the way they always do in that app, and the conversation continues with the request answered. The customer types their identity details at the scheme’s own login only when they follow a verification link; with the app approval they type nothing at all, because your record already names them.

Proving an identity unlocks that person’s own record only. A verification completes when the identity the scheme proves matches the identifier on the record the conversation is about, so an approval from anyone else changes nothing.

When something is wrong

Each failure is named where you can see it, rather than surfacing as a customer who was never verified:

What happens	What you see
The eID lookup is missing under Customer records	The country row reads “Blocked. Designate an eID identifier under Customer records first.” The method stays out of every conversation until the designation exists.
Broker credentials are missing	The country row reads “Blocked. Enter the broker client ID and client secret to activate this country”, and the per-channel National eID checkbox stays inactive with a hint pointing at the tab.
The broker offers the link form only	The row reads “This broker offers the verification link only”, and the app approval is withheld for that country.
Your record holds an identifier the broker cannot address	The row reads “Designate the identifier this broker addresses customers by, under Customer records.”
The customer declines the approval	The decline is recorded in Identity events, and the customer’s next message offers the other methods enabled on the channel.
The customer approves, and the identity proven belongs to someone other than the record names	The verification stays open, the attempt is recorded in Identity events, and the other enabled methods remain available. This protects your customers: an approval only ever unlocks the approver’s own record.

What oHallo stores

A completed verification stores the scheme, the broker, the level and your own customer reference, against the conversation. The national identity number is read from your record at the moment of the request, relayed straight to the scheme, and never stored, logged or shown to a model. The approval itself lives with the scheme.