Skip to content

2. iDIN Solution Overview

csg-coder edited this page Jan 22, 2019 · 16 revisions

This chapter contains a brief description of iDIN and the underlying iDx protocol. A more elaborate description can be found in the iDIN Merchant Implementation Guidelines (also available in Dutch), which is distributed along with this integration manual.

2.1 iDIN Roles

The following roles are used throughout this document:

Definition Description
Merchant The owner of a web application in which iDIN is an authentication method, and the user of the Software Libraries
Acquirer The acquiring bank with which the Merchant has a contract for iDIN
Routing Service The technical role of the Acquirer which handles the message exchange. Throughout this manual the Acquirer and Routing Service can be seen as the same party.
Consumer The consumer who uses iDIN provided by the Merchant
Issuer The bank that communicates on behalf of the Consumer
Validation Service The technical role of the Issuer that handles the message exchange

2.2 Basic product description

The iDIN services can be used for the following:

  • Login of Consumers;
  • Provisioning of Consumer attributes from the Issuer administration (i.e. Name, address, gender, date of birth or 18+ verification, telephone, email);
    • All attributes can be requested individually or in any combination. For example the attribute 18+ can be requested individually to be used for age verification.

Core principles of iDIN:

  • Consumer consent at the Issuer side is required explicitly for all iDIN services and provisioning of Consumer data, for every request initiated by the Merchant;
  • Consumers can be persistently identified using a Bank Identification Number (BIN), which will be Issuer generated (so not shared among Issuers) and unique per Consumer-Merchant combination. The BIN can be used to login Consumers;
  • A Consumer has only one identity per Issuer, regardless of the number of credentials;
  • Consumer information in messages will be shielded from Acquirers by means of end-to-end encryption.

2.3 Schematic overview of the iDIN Flow

iDIN uses the iDx standards as a messaging standard. It uses the generic information container in the iDx protocol to embed SAML 2.0 messages. iDIN uses the three iDx functions:

  • Directory protocol: This request is run between the Merchant and Routing Service. Its purpose is to retrieve the list of Issuers offering iDIN. The directory protocol can be run stand-alone.
  • Transaction protocol: This is run between the Merchant and Routing Service to process an authentication request. The transaction protocol is always followed by the status protocol;
  • Status protocol: This is run between the Merchant and Routing Service to retrieve the status of a previously processed authentication request, and if it is successful - also retrieve the values of requested data. The status protocol is always initiated after the transaction protocol.

2.3.1 Directory protocol (retrieve Issuer list)

Figure 1: Schematic overview of the Directory protocol

2.3.2 Transaction and status protocol (identify/login a Consumer)

Figure 2: Schematic overview transaction and status protocol (part 1)

Figure 3: Schematic overview transaction and status protocol (part 2)

Clone this wiki locally