-
Notifications
You must be signed in to change notification settings - Fork 3
2. iDIN Solution Overview
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.
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 |
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.
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)
The iDIN Software Libraries are a set of software libraries created to facilitate the integration of Merchants for supporting iDIN messages based on the iDx standards. The libraries are responsible for validating and authenticating incoming messages against its XML schema and certificates. The libraries save Merchants the need to implement all functionality described in the iDIN product and iDx standards.
The iDIN Software Libraries expose the following operations:
- Retrieve the list of the Issuers (implements a Directory Request at iDx level);
- Send an authentication request (implements a Transaction Request at iDx level);
- Retrieve the status of an earlier authentication request (implements a Status Request at iDx level).
Note: In this document the iDIN process of providing one of the above services is referred to as a iDIN transaction.
NB: The iDIN software libraries require communication with TLS 1.2, older versions of TLS/SSL are not supported. Please read the instructions how to configure TLS 1.2 in the relevant subsections.