Verifying with a national eID

National eID lets a customer prove who they are with their country’s own identity scheme. On a call the customer approves in their own eID app, on their own device; by email and in live chat they follow a verification link and sign in at the scheme. By default a completed verification verifies them at high assurance on its own, because the proof comes from the scheme rather than from anything oHallo infers; A verification counts as on the National eID tab sets the level (see The workspace settings). It is the strongest verification method oHallo offers, and the only one that reaches high-assurance (see Assurance levels).

The configuration screen offers Denmark, Norway and Sweden, and each connection’s row states plainly whether the method runs for your combination of scheme, provider 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. Under Settings, then Customer records, set up The customer’s CPR number and, where your own system keeps the MitID UUID, The customer’s MitID UUID, in the section Verifying with MitID. A call reads them from the tool behind By phone number, which finds the customer who holds the calling number, and email reads them from the tool behind By email address, which finds the customer who holds the address they write from, so set them up on those tools. On those two rows also choose Field with the phone number and Field with the email address: oHallo uses the customer a lookup returns only when that field holds the number or address it looked up. Each request reads the lookups of the connection that holds the tool it needs, so set them up on each connection with a request that only National eID verifies on a call or by email. See Finding your customers.
A connection with provider credentials, set up on the National eID tab as described below.
National eID switched on for the channel. It runs on voice and live chat channels and on email channels set up to receive mail directly; you turn it on per channel.

Adding a connection

Open Settings, then Verification, then the National eID tab. Click Add connection. A connection is your agreement with one eID provider for one eID, with its own credentials: a Client ID and Client secret, or for BankID, direct in Sweden a relying-party certificate. Each connection appears as its own row on the tab.

The panel first asks for:

Country. Denmark verifies with MitID, Norway and Sweden with BankID. The panel shows the eID once the country is chosen.
Provider. The company your eID agreement is with. The list shows the providers serving that eID: Signaturgruppen serves Denmark, while Idura, Scrive and ZignSec serve all three countries. Norway and Sweden also list BankID, direct, which uses your own registration at the scheme itself: a BankID merchant registration in Norway, a relying-party certificate from your bank in Sweden.

The rest of the panel follows your provider’s own dashboard, in three groups. At Idura they read as follows.

Copy from Idura. Open Applications in the Idura dashboard and choose your application. A new application needs the Application Type Regular Web Application, so that Idura gives it a client secret.

Domain. As your application in the Idura dashboard shows it, with or without https://. oHallo checks it with Idura when you save. Signaturgruppen, Scrive, ZignSec and BankID, direct use one address for every customer, so the panel asks for no domain there.
Client ID. On your application’s General tab, under Client ID/Realm.
Client secret. Idura shows it once, when the application is created. To get a new one, open your application’s OpenID Connect tab, switch on Enable OAuth2 Code Flow and save. A new connection saves once its secret is entered. The secret stays in place until you replace it, and the panel shows that one is saved rather than the value itself.

Set up at Idura.

Redirect URL. Shown read only, with a copy button. Add it under Redirect URLs on your application’s General tab, exactly as shown. Idura returns the customer to oHallo at this address after the MitID login, and accepts only addresses registered in advance. Other providers name the same address in their own words, such as a redirect address.
Caller Authentication with MitID. Needed for MitID approvals on phone calls. Caller Authentication with MitID needs to be part of your agreement with Idura; tick this when it is.
CPR number in MitID logins. Lets the verification link compare the CPR number where your system holds no MitID UUID. Tick it when these three steps are done in the Idura dashboard:
1. Under eID providers, Danish MitID, switch on Add CPR for MitID logins.
2. On your application’s OpenID Connect tab, set JWT property format to compact.
3. On your application’s General tab, check that Scope strategy is Dynamic.

Both ticks belong to one Idura application, so changing the Domain or Client ID of a saved connection unticks them, and the panel says so; typing the saved Domain or Client ID back ticks them again.

MitID.

Your company name in MitID. Filled in with your brand’s name, up to 130 characters, and required while the connection is switched on. The app shows it first in every request, before oHallo’s text, so name yourself the way your customers know you. Under the field the panel shows what the app shows on a call with the longest text oHallo adds: your name, then that sentence, in your workspace’s operating language (on a call itself, in the language of the voice channel). The app shows 130 characters in all, so a long name gives way from its end, and the panel then says what the app shows. With Reading, with each change approved on its own, a request on a call that names an order or another record carries its reference too, and the name can then give way to its first 20 characters. A Swedish BankID connection asks for Your company name in BankID the same way.
MitID level, on a connection that runs at High: Substantial (recommended) or High. High turns away customers who have neither a MitID app set up at level high nor a MitID chip. A new connection runs at Substantial, the level Idura recommends.
Accept MitID Erhverv (MitID at Idura and Signicat). An employee or a company signatory signs in with MitID Erhverv, the business login a company registers its people for, and reaches the records of the company whose registration number your record holds, on tools set to A customer’s company. It needs, under Customer records, the field with your account number for the company and the field with the company’s CVR number on The customer’s CPR number or The customer’s MitID UUID, or Only the company’s CVR number, and the connection’s readiness line for MitID Erhverv says when it runs. At Signicat, allow the mitid-business scope, which comes with Signicat’s MitID Business add-on.
Enabled. Whether customers verify through this connection on channels where National eID is switched on.

BankID, direct in Sweden asks for its Relying-party certificate and Certificate passphrase in place of the Client ID and Client secret. Upload the certificate file your bank issued and enter its passphrase. The panel then shows the certificate’s serial number and the date it is valid until, and the stored certificate stays in place until you replace it.

Save, and the connection appears as a row on the tab, showing its country and eID, its provider and its readiness line. When a field needs a change, the panel says so under that field and saves nothing, for example “oHallo could not find this domain at Idura. Check it matches the Domain on your Idura application.” Country, eID and provider stay fixed on a saved connection; to move to another provider, add a new connection.

At Idura, oHallo reads the customer from the ID token Idura signs. In your Idura application, keep the id_token response strategy on signedJwt, set the User info response strategy to fromTokenEndpoint, and choose default or compact as the JWT property format. The MitID UUID your system holds is read in both formats. The CPR number is read in the compact format. Under the dynamic scope strategy only a verification link that compares the CPR number asks Idura for it, so a customer verified on the MitID UUID is never asked for their CPR number.

Reading the readiness line

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

Ready. The app approval and the verification link both run. Customers can verify through this connection either way.
Ready. The app approval runs. Customers can verify through this connection with the approval in their app.
Ready. The verification link runs. The link form of the method works for this connection.
Blocked, followed by what is still needed, one step per line, for example “Enter the Client ID and Client secret from Idura on the connection.” or “Under Customer records, set up “The customer’s CPR number” or “The customer’s MitID UUID”, whichever your provider uses.” Customer records in a step links to that page.
Blocked. National eID is switched off for this workspace. Every connection reads this line while the switch on the tab is off (see The workspace settings).

Where one way runs and the other is blocked, the row shows both: the Ready line for the way that runs, then a Blocked line that names the other way and what it still needs, for example:

Ready. The verification link runs.
Blocked. The app approval on phone calls: Under Customer records, set up “The customer’s CPR number” or “The customer’s MitID UUID”, whichever your provider uses.

A way your provider does not offer adds no line.

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 connection with provider credentials is switched on; before that, it points you back at the National eID tab.

Under Will a customer be verified? on the Channels tab, each channel’s row then shows a line for National eID under the channel’s methods, read from the same readiness as the connection rows: on a voice channel, for example, “Ready. The customer approves in their national eID app (MitID).”, and on an email or live chat channel “Ready. The customer signs in with their national eID through a link (MitID).” A line that reads Blocked lists what is still needed, one step per line, such as a lookup under Customer records on a connection it names; Customer records in a step opens that connection’s page, or the Customer records list where the step names several. While National eID is switched off for the workspace, the line reads “Blocked. National eID is switched off on the National eID tab.” Read it before you go live.

The workspace settings

The National eID tab carries four settings for the whole workspace, which owners and admins change and save with the Save button at the foot of the page:

The switch beside the tab’s introduction turns National eID on or off. National eID runs on a channel while this switch, the connection’s own Enabled and the channel’s National eID choice are all on and a connection is ready. Switching it off stops every connection at once: no customer is asked to verify with National eID, and a National eID verification already given in an open conversation stops counting. A connection switched off with its own Enabled asks no customer from then on, and a verification already given through it counts until its time runs out. Your connections and each channel’s choice stay as they are while the switch is off.
A verification counts as: high-assurance, the default, or identified, for every connection’s verifications. This is oHallo’s level, separate from the level the connection runs at the provider (MitID level). At identified, no channel reaches high-assurance, and a line under the setting counts the tools that need it (see Assurance levels).
What one verification covers: Everything the customer asks in the conversation, the default, or Reading, with each change approved on its own. See What one approval covers.
After the customer declines: Hand the conversation to your team, the default, or Let the customer verify another way. See When verification fails.

The three settings under Policy show while the switch is on and a connection exists. The Levels table on the Posture tab and the Reachable by column on the MCP hub follow a change once it is saved.

On calls, by email and in live chat

On a phone call the approval always goes to the app, because the caller is present on the line, and it goes to the customer whose record holds the number the caller is calling from in the system the request needs, whatever the request is about. See Verifying on a phone call.

By email the reply carries a verification link, sent to the address the customer wrote from, on email channels set up to receive mail directly, for mail whose sender oHallo confirms. The link is tied to the customer whose record holds that address in the system the request needs, whatever the request is about, so a customer who asks about another customer’s order can only ever sign in as themselves. The verification page names the request and the masked address it came from, and says that signing in covers the whole conversation, changes that cannot be undone included, and their company’s information too when their record names a company. One sign-in covers everything the customer asks in that email conversation. When no record holds the address the customer writes from, a request about a specific record that needs high-assurance goes to a colleague, and one that needs identified uses the email link to the address on that record, where it is enabled.

MitID Erhverv. When a request reads the records of the customer’s company and the customer’s record names that company with its registration number, the verification link offers MitID Erhverv beside MitID. A record that names a company but no person identifier is verified with MitID Erhverv. For a system that holds only company numbers, set up Only the company’s CVR number with the fields for your customer number, your account number for the company and the company’s CVR number (see Finding your customers). A MitID Erhverv login is compared on the company registration number alone: when it matches the record’s, the employee is tied to that company and reaches the company’s records, never one customer’s own records; a different number is a decline. A customer who holds a verification with their private MitID that is still in force cannot add one with MitID Erhverv, or the reverse; the conversation then continues as your setting After the customer declines says. MitID Erhverv runs on the verification link, by email and in live chat; the approval in the app on a phone call is private MitID.

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. The verification page names the request, says that the request came from a live chat with you, and says that signing in lets that chat see the customer’s information and covers the whole conversation, changes that cannot be undone included. One sign-in covers everything the customer asks in that chat. See Live chat and the chat widget for what the visitor sees, including what happens when a button expires.

The verification page and the email that carries its link are in your workspace’s operating language, the language the assistant writes in by email and in live chat.

A MitID verification is valid for at most 5 hours.

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. On a call, the approval appears in the eID app of the customer whose record holds the calling number, showing the message you configured and the provider name; they approve the way they always do in that app, and the call continues with the request answered, without the caller typing anything, because your record already names them. By email and in live chat, the customer follows the verification link and signs in at the scheme’s own login, and the conversation continues with the request answered. Where the link compares the CPR number, Idura asks the customer for it during the MitID login and checks that it belongs to 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 request goes to: on a call the record that holds the calling number, by email the record that holds the address the customer writes from, in live chat the record the customer named. An approval from anyone else changes nothing.

What one approval covers

By default, one approval or sign-in covers everything the customer asks in that conversation for as long as it counts: reading their information, and changes to it, including changes that cannot be undone. The request says so before the customer approves: on a call the app says the approval covers the whole call, even changes that cannot be undone, and by email and in live chat the verification page says the same of the conversation. The same change, asked for twice, is carried out once.

With Reading, with each change approved on its own chosen under What one verification covers, one approval covers reading the customer’s own information in that conversation for as long as it counts, and each change, and each request that cannot be undone, is approved on its own: the approval names the change and covers that change exactly, the same tool with the same details, and a different change asks again. On a call the app then says what the call asks for, from the risk classification of the tool the request needs (see Guardrails): a read or read (PII) tool asks to see the customer’s information, a write or write (PII) tool asks to change it, and a destructive tool names a change that cannot be undone.

It covers the customer’s own records, whatever record a request names: on a tool declared A customer, the records your system says are theirs. It covers the records of their company, on a tool declared A customer’s company, when your system names that company in the field with your account number for the company and they signed in on the verification link, by email or in live chat, whose page then names their company’s information too; the approval in the app on a phone call covers the caller’s own records. A verification counts for the connected system the request went to, so the first request to another system’s customer records starts a verification of its own. Another customer’s records stay withheld whatever is approved. See Finding your customers for how tools are declared.

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, or names an identifier the provider is unable to address	The connection row reads “Blocked. Under Customer records, set up “The customer’s CPR number” or “The customer’s MitID UUID”, whichever your provider uses.” The method stays out of every conversation until the row is set up.
The Client ID and Client secret are missing	The connection row reads “Blocked. Enter the Client ID and Client secret from Idura on the connection.”, naming the connection’s own provider. For BankID, direct in Sweden it reads “Blocked. Upload the relying-party certificate and enter its passphrase to activate this connection.” The per-channel National eID checkbox stays inactive with a hint pointing at the tab.
A connection with a request that only National eID verifies on a call has no By phone number with its field with the phone number, or has it on another tool than the identifier	The app approval runs for the tools of the connections that have them, and a voice channel’s line under Will a customer be verified? reads “Blocked. Set up “By phone number” with the field that holds the phone number under Customer records on Order system, on the same tool as the CPR number or MitID UUID.”, with the name of each connection that still needs it. While no connection holding a tool the app approval opens has them, the line names each such connection, also where another method verifies their requests on calls. A tool declared A customer’s company opens through the verification link, by email and in live chat, and never through the app approval, so it decides nothing on this line.
A connection with a request that only National eID verifies by email has no By email address with its field with the email address, or has it on another tool than the identifier	The verification link by email runs for the tools of the connections that have them, and an email channel’s line reads “Blocked. Set up “By email address” with the field that holds the email address under Customer records on Order system, on the same tool as the CPR number or MitID UUID.”, with the name of each connection that still needs it. While no connection whose tools ask customers to verify has them, the line names each of them, also where another method verifies their requests by email. Live chat keeps its link.
A tool declared A customer’s company sits on a connection whose By email address tool has no field with your account number for the company	The verification link by email ties the customer to no company there, so requests to that tool go to a colleague, and an email channel’s line reads “Blocked. Choose the field with your account number for the company on “The customer’s CPR number” or “The customer’s MitID UUID” under Customer records on Order system, for the tool behind “By email address”.”, after the step for a missing By email address where one is missing too.
A request in live chat that only National eID verifies reaches a tool whose record the verification link cannot find	The live chat channel’s line under Will a customer be verified? reads Blocked and names each tool with the step it needs, one step per line: The customer’s CPR number or The customer’s MitID UUID on the tool’s own row, for a tool that reads; the choice A customer or A customer’s company, for a tool that changes something; one of those rows on a tool in the same system that takes the same input, for a tool set to one of those choices, for example “Blocked. Set up “The customer’s CPR number” or “The customer’s MitID UUID” on a tool in the same system that takes the same input as cancel_order in Order system, under Customer records.”; that row on only one such tool where two take that input; and the field with your account number for the company, on The customer’s CPR number or The customer’s MitID UUID for the tool the link reads, for a tool set to A customer’s company. A tool set to A customer’s company, and a tool set to A customer and to `high-assurance` or that changes something, opens only with National eID at `high-assurance`. A tool set to A customer and to `identified` that reads is named here only where the email link does not reach it in live chat: the email link’s line, where the email link is on, then names its step (see Finding your customers). A tool set to General information, for anyone is named on no line, as no lookup can be set up on it; its Reachable by cell on the MCP hub page says whether another method reaches it.
An email channel receives mail by forwarding or from a connected Microsoft 365 mailbox	National eID runs on email channels set up to receive mail directly, where oHallo checks who sent each message. That channel’s line reads “Blocked. National eID runs on email channels set up to receive mail directly.” Customers writing to it reach `identified` with the email link where it is on; a request that needs `high-assurance` goes to a colleague.
A MitID connection at Idura has Caller Authentication with MitID unticked	The app approval stays out of calls for that connection until it is ticked, and a voice channel’s line under Will a customer be verified? reads “Blocked. Tick “Caller Authentication with MitID” on the connection.” Where the connection’s verification link is blocked too, the connection row is Blocked with the same sentence.
A MitID connection at Idura has CPR number in MitID logins unticked	The verification link compares the MitID UUID alone until it is ticked. Where your system holds the CPR number without the MitID UUID and the connection’s app approval is blocked too, the row is Blocked with “Tick “CPR number in MitID logins” on the connection when it is set up at Idura.”
A verification link that compares the CPR number ends with `identifier_claim_absent` in Identity events	The provider’s login carries no CPR number. At Idura, check the three steps named under CPR number in MitID logins.
A MitID connection is switched on without your company name in MitID	The app approval stays out of calls for that connection until the name is entered. Where the connection’s verification link does not run either, the row is Blocked with “Enter your company name in MitID on the connection.”
Two connections are ready for the same way of verifying	Each affected row reads “Blocked. Another connection in this workspace is also ready for this leg, so every request declines; switch one off.” Keep one of them switched on.
A certificate has passed its valid-until date	The row reads “Blocked. The certificate for this connection has expired; upload a new one to activate it.”
The customer declines the app approval	The decline is recorded in Identity events. No further request goes to the customer’s app and no further verification link is sent in that conversation, and the assistant gives no reason. What follows is the setting After the customer declines: with Hand the conversation to your team, the default, anything verified earlier in the conversation stops counting and a colleague takes over: on a call the assistant offers to bring one in, and by email and in chat a teammate is notified and follows up. With Let the customer verify another way, the customer verifies with the other methods on the channel, such as the email link, for requests that need `identified`, and a request that needs `high-assurance` goes to a colleague. The record the request was sent through is marked declined until the end of its window: under Customer records, the contact page shows “Declined National eID until” with the date and time the decline stops applying. Until then the record’s app approvals are used up in every conversation. A later verification with the customer’s private National eID ends the mark.
The customer approves or signs in, and the identity proven belongs to someone other than the record names	Nothing is verified, the attempt is recorded in Identity events, and it counts as a decline in the conversation that started it, with the same outcome as above. This protects your customers: an approval only ever unlocks the approver’s own record, and a sign-in on a link meant for someone else ends only the verification of the conversation that asked for it.
After following a verification link, the customer cancels the login on the scheme’s own login page, or the scheme ends the login there without a result	The page tells the customer the login was not completed and asks them to return to the conversation and open the link again. The link stays usable until it expires, nothing else in the conversation changes, and Identity events records the attempt with the result `provider_error` and the provider’s error code, at most once in 15 minutes for the same link. With BankID, direct in Sweden, the BankID step runs from the verification page itself: a cancel in the BankID app shows “We could not verify you for this request”, and the same link can be opened again until it expires.

What oHallo stores

A completed verification stores the scheme, the provider, the level and your own customer number, 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.