Verifying on a phone call

A caller can verify with their national eID during a live call. The assistant stays on the line, the approval appears in the caller’s own eID app, and the caller approves there. The whole exchange happens between the call and the app: the caller stays on the phone from start to finish, and the browser plays no part.

The National eID tab under Settings, then Verification states per connection whether the method runs, and its readiness line is the authority for your workspace.

What it needs

A working phone-number lookup. The approval goes to the customer whose record holds the number the caller is calling from, so the By phone number row under Settings, then Customer records has to be working, with its Field with the phone number chosen, on the same connection as the tools the caller’s requests use and on the same tool as the identifier below. The assistant uses the customer your lookup returns only when that field holds the number the caller is calling from, written in any form: with or without spaces, the international form or the national form. The voice channel’s line under Will a customer be verified? on the Channels tab reads Ready once each connection with a request that only National eID verifies on that channel has it, and names each one that does not. While no connection holding a tool the app approval opens has it, the line names each such connection; a tool declared A customer’s company opens through the verification link, never through the app approval, so it decides nothing here. See Finding your customers.
The customer’s identifier. The approval is addressed from your own system, through the The customer’s CPR number row or, where your provider addresses approvals by the MitID UUID, the The customer’s MitID UUID row, under Verifying with MitID.
A connection for Denmark. A MitID connection on the National eID tab, with its Client ID and Client secret saved, your company name in MitID, and the connection switched on. At Idura, also tick Caller Authentication with MitID, which needs to be part of your agreement with Idura. The full setup is described in Verifying with a national eID.
National eID switched on for the voice channel. On the Channels tab, click Customise on the voice channel and tick National eID.

What the caller experiences

The caller asks about something that touches their account, such as an order or an invoice.
The assistant finds the record in your own system that holds the number the caller is calling from, asks the caller to open their MitID app, and stays on the line while they do. When the caller asks about an order or an invoice that is not on that record, the request still goes to the caller’s own app, never to another customer’s.
The approval appears in the app with the provider name, the message you configured and a line, in the language of the voice channel, saying the request belongs to the call the caller is making to you now (or your call to them) and, by default, that approving covers the whole call, even changes that cannot be undone. The message you configured is shortened first to make room for that line.
The caller approves the way they always do in MitID, and the call carries on where it left off, with the request now unlocked at high assurance by default (the level A verification counts as sets on the National eID tab).

By default one approval covers the whole call: the assistant reads the caller’s own information and carries out the changes they ask for, including ones that cannot be undone, without asking them to approve again. A request to another connected system’s customer records sends an approval of its own. 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 on the National eID tab, one approval lets the assistant read the caller’s information during the call, and each change is approved on its own. The line in the app then says what the call asks for, from the risk classification of the tool the request needs, set on Guardrails: to see their information, to change it, or a change that cannot be undone. A request to change something, or one that cannot be undone, sends a new approval that names it, and the assistant carries out exactly the change the caller approved, once.

The caller’s part is the approval in the app, and that is the whole of it. The identifier that addresses the approval is read from your own record at that moment and relayed straight to the scheme, so the caller keeps their personal details off the call: they read nothing aloud and type nothing on the keypad, and the number stays out of the transcript entirely.

The approval arrives in the MitID app, so the caller needs that app on their phone. A caller who uses a code display continues as described below.

When the caller cannot approve

When the request closes before the caller acts on it, the assistant tells them on the call that it was not completed and offers to verify again. The next verification is chosen the way the first one was, from the methods you have enabled on the voice channel.

When the caller declines the request in the app, or someone other than the caller approves it, no request is sent to their app again during that call, and anything verified earlier in the call stops counting. The assistant tells the caller that no new request can be sent to their app on this call, gives no reason, and offers to bring in a colleague: a transfer, or, when no one can take the call, a callback where the voice channel is set to Offer a callback.

A caller who uses a MitID code display rather than the app tells the assistant so. The assistant does not ask them to open the app again. Once the request in the app has closed, it sends a secure link to the email address on file for what the caller asked about, where the Email link is enabled for the voice channel. The link verifies the caller at identified, so a request that needs high-assurance goes to a colleague instead: a transfer, or, when no one can take the call, a callback where the voice channel is set to Offer a callback.

When no record holds the number the caller is calling from, the customer your lookup returns holds another number in the field with the phone number, or that customer holds an identifier the provider is unable to address, no request is sent, and the caller verifies with the Email link where you have enabled it, exactly as on a call where National eID is switched off; a request that needs high-assurance goes to a colleague.

Each attempt is recorded in Identity events, so you can see which method verified each caller and why.