v2 – eID: BankID in Browser -no -fi

Set up of identity number. This optional parameter has somewhat different meanings for each country:

SE: Means that for Sweden only this specific person can be identified; No need to fill in PersonalNumber; The BankID app starts up for this person only.

DK: Danish Nemid does not return personal number (CPR), instead a technical substitute key called PID. However, if the PersonalNumber parameter is present then a background matchPidCpr call is run that verifies that given PersonalNumber matches the logged-in PID, Where after the PersonalNumber is set in response symbolizing the PersonalNumber is verified by a NemID login.

NO: If PersonalNumber is sent in only that person can login, because the first page for entering PersonalNumber is skipped entirely. This is a convenient way to verify a specific PersonalNumber. Another alternative is the field Additional_identity_info that lets you include the PersonalNumber in the results provided the BankID merchant certificate used is allowed for fetching extra info.

The PersonalNumber formats per country:

SE: personalNumber=195206040759 (YYYYMMDDCCCC)

DK: personalNumber=1210312133 (DDMMYYCCCC)

NO: personalNumber=01129955131 (DDMMYYXXXCC)

This semi-optional parameter will be returned to you at the redirect back to your server. Use it to link an unique ID of your choice that you can parse. If not relaystate is specified, ZignSec will automatically set the ZignSec’s unique session identifier, the RequestID token here.

Example: relaystate=zignsec_eid_1234

Here you can send in a GUID that represent a specific configuration. This is used to separate between multiple certificates, different layouts or to make different Webhook calls. If only one configuration it is used automatically.

Example: configid=d638a4ab-7382-4c5d-98e8-e90d3aa3e1be

If this parameter is supplied the browser session will finally be redirected to this URL-value. The URL-parameter value must be URL-encoded.

Example: target=http%3A%2F%2Flocalhost%3A8080%2Fzignsec%2Freturn will result in a browser redirect to for example http://localhost:8080/zignsec/return?relaystate=96a09f3f-b764-4ed0-b9e8-2b29d95dcf15&service=eIDBasic where relayState is ZignSec’s session token (RequestID) which can be used to retrieve the results from the login session.

Decides web form user interface language.

The default language is taken from the merchants setting ‘DefaultLanguage’ or EN=English if none is set there. Language can be changed both on a request level here, or on setting level. For example, if a customer mainly uses the Swedish BankID ZignSec will change the ‘DefaultLanguage’ setting to SV for best user experience. The code format should be in this 2-letter ISO 639-1 language code, case-insensitive.

Only works with Danish NemID [who don’t return the Danish personal number (CPR)]. This merchant callback allows for a slimmed login process, showing the CPR validation dialog only when necessary (such as on a customer’s first login to a site). If this callback is present the merchant can decide in runtime whether the CPR validation is needed or not. A callback URL parameter can be for example: AskForCprCallback=https://someone.com/AskCpr?pid=@IdProviderPersonId@.

Process details: a GET to the URL will be issued by ZignSec with the PID from NemID-login replaced at @IdProviderPersonId@. If the response json is {"askForCpr":true} this means we should next show the CPR entry dialog and run CPR validation step. The validated CPR will be stored as usual in the PersonalNumber field in the identity response. Observer that all other return values or errors will result in the dialog NOT be shown and the CPR validation can not be run.

Our recommendations: * Since the PID is always returned it can be stored together with a verified CPR after first NemID login, and then on the next visits you don’t need to show the CPR dialog since the PID can be used as the unique lookup key to find the known customer. * Also keep in mind that if the customer´s CPR is known in advance it can be sent in with the PersonalNumber parameter with the NemID initiation, and the CPR will be silently verified with a Match call and if correct be put in the PersonalNumber response field.

Only works with Norwegian BankID and when method is set to nbid_oidc, see bankidnorge login hints .

For example BID restricts to web login, BIM restricts to mobile login, BID:07025312345 restricts to person with given national identity number and omits the first user dialog, BID:07025312345 performs the same person restriction but keeps the initial selection dialog for selecting between web and mobile login.

Currently works for Swedish BankID and Swedish Banking API. If set to true will automatically do a Swedish person address lookup from the verified personalNumber using LookupPerson API and the official population register. The call is charged separately, which means that additional charges will be incurred.

For a response example go here.

A url where success/error results will automatically be POST:ed. It can be set either here or on the merchant’s setting, see this general page web hooks for success and error

During test you try https://webhook.site/ for free web hook URLs.

NOTE: Include setting AutoStartTokenRequired=Yes to require that login must be performed scanning a QR code. Adding this setting will also show the QR-code on the waiting form.

Used by RP to set requirements how the authentication or sign operation
must be performed. Default rules are applied if omitted.

Example: { "AutoStartTokenRequired": "Yes" }

Optional, default is false. Allows for building long-running login workflows, ex sending the redirect_url with an email, and allow the user to make many attempts to login. The redirect_url link in the response also has a time-out period parameter set through merchant settings called RedirectUrl_ExpirationInMinutes_Test / RedirectUrl_ExpirationInMinutes_Prod.

Default expiration setting is 7 days.

Example:{ "allowRetries": true }

Only works with Norwegian BankID . Following scope values can be used as space separated string: nnin, address, phone, email– will prompt end user consent for sharing data; nnin_altsub – will not prompt end user consent for sharing data.

Note: nnin_altsub can’t be used for onboarding new customers if you don’t already process their national identity number. For onboarding purposes, nnin  must be used, which prompt end user consent for storing this data point.

Example:{ "Scope": "nnin address phone" }

Above example will prompt consent to provide national identity number, address and phone.

Works with nbid_pep only. Configures Environment and DataSource (See Watchlist DataSource for more information) for PEP Check.

Example:

{
"PEP_Check": {
"DataSource":"GLOBAL",
"Environment":"Test"
}
}