Page Comparison

1.1 Doelgroep

Dit document geeft een gedetailleerde beschrijving van iDIN van de Nederlandse banken. Het document is bedoeld voor degenen die gedetailleerde informatie behoeven ten aanzien van deze oplossing.
Dit document is bedoeld voor Acceptanten die aan willen sluiten op het iDIN platform van hun bank. Het behandelt het berichtenverkeer tussen Acceptanten en hun bank. Voor Acceptanten is het berichtenverkeer tussen Acquirer en Issuer niet van belang. Dit deel van de iDIN Standaard wordt daarom in dit document niet behandeld, tenzij de berichten van belang zijn voor de implementatie van de Acceptant worden deze beschreven.
Dit document is niet bank-specifiek; dit wil zeggen dat alleen generieke iDIN zaken in dit document worden behandeld. Informatie over non-standaard aansluitvormen bij specifieke Acquirers en de hulp-(middelen) die een Acquirer verstrekt om aan te sluiten op iDIN zijn geen onderdeel van dit document. Voor informatie over deze onderwerpen verwijzen wij u naar de door uw Acquirer verstrekte (aanvullende) documentatie.

Om updates van dit document te ontvangen kunt u zich wijzigingen op deze pagina op Confluence abonneren. 

Om Acceptanten en Digital Identity Service Providers (DISPs) verder te ondersteunen, zijn er Software Libraries ontwikkeld in .NET, PHP en Java. De software libraries staan gepubliceerd op github.com (via https://www.idin.nl/softwarelibraries/) of neem contact op met uw Acquirer voor meer informatie betreffende deze Software Libraries. Om updates van de software libraries te ontvangen kunt u zich abonneren op github.com.

1.2 Document opzet

Dit document heeft de volgende structuur:

• Hoofdstuk 1: Inleiding
• Hoofdstuk 2: Introductie van iDIN en de betrokken partijen;
• Hoofdstuk 3: Introductie in de verschillende berichten binnen iDIN en de algemene structuur van de uitgewisselde berichten;
• Hoofdstuk 4: Algemene berichtgevingsstandaard;
• Hoofdstuk 5: Data catalogus; Alle parameters die relevant zijn voor de Acceptant in de iDIN omgeving;
• Hoofdstuk 6: Directory protocol: Ontvangen van de lijst van Issuers die iDIN aanbieden;
• Hoofdstuk 7: Transaction protocol: Aanvragen van Gebruikersattributen, identificatie of leeftijdsverificatie;
• Hoofdstuk 8: Status protocol: Ontvangen van de Gebruikersattributen;
• Hoofdstuk 9: Error handling;
• Hoofdstuk 10: Beveiliging en certificaten;
• Hoofdstuk 11: Presentatie van iDIN op de website van de Acceptant;

1.3 Andere referenties

^{Tabel 1: Referenties}

1.4 Conventies met betrekking tot notaties

Berichten en redirects worden geschreven als dit, en data elementen worden geschreven als dit.

1.5 Definities van online bankieren

In dit document worden de termen 'internet bankieren' en 'online bankieren' gebruikt. Voor banken van de Gebruiker die iDIN mobiel implementeren, zouden deze termen geïnterpreteerd moeten worden als 'internet bankieren' en/of 'mobiel bankieren'. Waar internet of online gerelateerde terminologie gebruikt wordt, moet dit altijd gelezen worden als ook betrekking hebbende op het mobiele kanaal. In geval het mobiele gebruik van iDIN tot aanvullende vereisten (requirements) leidt, zullen deze specifiek benoemd worden in onderhavige Implementatie Gids.

1.6 Revisies

^{Tabel 2: Revisie tabel}

1.7 Wijzigingen in vergelijking met eerdere versies

Veranderingen ten opzichte van versie 1.00

1. Toevoeging foutafhandeling als de Issuer niet kan voldoen aan de minimale set van Consumentenattributen: Twee elementen zijn toegevoegd in het AcquirerStatusRes (DeliveredServiceID en een tweede SAML status code). Deze geven informatie aan de Acceptant als de Issuer niet alle attributen kan leveren conform de gedefinieerde minimale set (zie Sectie 5.5). De foutafhandeling staat beschreven in Sectie 12.4;
2. Toevoeging apart kunnen aanvragen/terugsturen van het geslacht van de Consument: De Acceptant kan nu het geslacht van de Consument apart aanvragen met het RequestedServiceID, waar dit attribuut voorheen onderdeel was van de attribuutgroep naam.;
3. Toelichting op het formaat van DateTimestamp (in alle varianten, zoals de createDateTimestamp): Acceptanten mogen nul tot drie decimalen achter de seconde gebruiken in de DateTimestamp van de berichten die ze naar de Routing Service sturen. De berichten die de Acceptant vanuit de Routing Service ontvangt bevatten wel altijd drie decimalen achter de seconde. Zie Tabel 11.

Veranderingen ten opzichte van versie 1.04

1. Toevoeging aanbeveling teksten Acceptantschermen: Dit is beschreven in hoofdstuk 11.8;
2. Aanscherping standaard Consumentberichten: Dit wordt beschreven in hoofdstuk 12.5.
3. Enkele kleine verduidelijkingen toegevoegd:
   1. In het formaat van DateTimestamp in Tabel 10 is toelichting toegevoegd dat YYYY staat voor het kalenderjaar, en dat 24-uurs notatie gebruikt moet worden;
   2. In de beschrijving van het formaat van TransactionID in Tabel 10 is toegevoegd dat de eerste vier cijfers zijn opgemaakt uit het AcquirerID;
   3. In de beschrijving van het tonen van de laatste inlog door de Acceptant in Sectie 11.8.1 is toegevoegd dat de datum en tijd getoond moeten worden (i.p.v. het tijdstip). Daarnaast is de reden voor deze eis toegevoegd, namelijk dat de Consument dan zelf kan controleren of dit tijdstip overeenkomst met zijn/haar laatste bezoek)
   4. In Appendix B is de kolom 'product type' toegevoegd die aangeeft welk ServiceID hoort bij welke product type;
   5. Toevoeging aanbeveling op het gebruik van TLS in hoofdstuk 10.1: Acceptanten worden geadviseerd om TLS versie 1.1 of hoger te gebruiken. Het gebruik van TLS versie 1.0 wordt afgeraden, omdat deze versie is verouderd.

Veranderingen ten opzichte van versie 1.041

1. De bit-structuur van het RequestedServiceID en DeliveredServiceID zijn heringedeeld (zie sectie 5.3.1) om het telefoon- en emailattribuut toe te voegen. De herindeling heeft geen impact op de integere waardes van het ServicesID en is daardoor backwards compatible;
2. Het telefoon- en emailattribuut zijn toegevoegd in Tabel 13;
3. Update van de Issuer front-end teksten die aan de Gebruiker worden getoond afhankelijk van de attributen die zijn aangevraagd door de Acceptant (zie Sectie 11.9.1)
4. Appendix B is verwijderd. Deze Appendix bevatte alle mogelijke integere waardes van het RequestedServiceID. Door de toevoeging van het telefoon- en emailattribuut zou deze tabel te groot zijn geworden. De Excel '160529A_ServiceID_Calculator' die samen met deze implementatie Gids wordt verstrekt biedt de mogelijkheid om gemakkelijk het ServiceID te berekenen;
5. In de toekomst zullen verouderde TLS versies niet langer worden ondersteund door de Routing Service. Daarom moet de Acceptant minimaal TLS versie 1.2 gebruiken (zie Sectie 10.1);
6. Kleine correcties en verduidelijkingen:
   1. In Sectie 10.2.1 is toegevoegd dat het X509SubjectName element mag worden inbegrepen door de Validation Service in het Signature element binnen de Assertion;
   2. In Sectie 10.3 is toegevoegd dat xsi type definities mogen worden gebruikt binnen het AttributeValue element door de Validation Service;
   3. Toevoeging van het Issuer.x509 data element in Tabel 11. De beschrijving van dit element ontbrak;
   4. Verwijdering van errorcode SE2000 en wijziging van errorcode SE2100 naar SE2700 (Invalid electronic signature). SE2000 en SE2100 worden niet gebruikt in iDIN;
   5. Update van de versleuteling voorbeelden en versleutelde voorbeeld berichten met de volledige namespace declaraties. De namespace declaraties stonden niet in de voorbeelden;
   6. Enkele namespace prefixen en de afsluitende tag van het eerste StatusCode element zijn toegevoegd in het voorbeeld in Sectie 12.2. Enkele namespace prefixen en de afsluitende tag ontbraken;
   7. Het tonen van de laatste login aan de Gebruiker in Sectie 11.8.1 is veranderd van verplicht naar sterk aangeraden;
   8. Update van de Merchant.LegalIDs in de voorbeeld berichten met geldige controle getallen.

Veranderingen ten opzichte van versie 1.05

1. Voorbeelden en verduidelijkingen zijn toegevoegd aan de gebruikersattributen
2. Annex diversiteit in gebruikersattributen toegevoegd

Veranderingen ten opzichte van versie 1.053

1. Toevoeging van §2.5.1 met hierin de beschrijving hoe DISP hun Acceptanten dienen aan te sluiten
2. Toevoeging van §5.5.1 met hierin de beschrijving hoe Gebruikers hun telefoonnummer en emailadres kunnen de-selecteren en wijzigen

Veranderingen ten opzichte van versie 1.06

1. Het gebruik van LoA2 voor iDIN wordt per 1 mei 2018 gestopt Alle referenties aan LoA2 zijn verwijderd uit het document.
2. Consumenten initialen mogen ligaturen en diakrieten bevatten (bijvoorbeeld á, ç, Æ).

Veranderingen ten opzichte van versie 1.07

1. Beschrijving van de rol van DISP/ondertekendienst (Signing Service Provider (SSP)) is toegevoegd.
2. Product type Ondertekenen is toegevoegd

Veranderingen ten opzichte van versie 1.08

1. Toegevoegd EPC richtlijnen voor landspecifieke informatie over de uitgifte van het CreditorID; dezelfde legal identifier als het LegalID.(https://www.europeanpaymentscouncil.eu/document-library/guidance-documents/creditor-identifier-overview).

2. /wiki/spaces/MRR/pages/1398964229e mogelijkheid toegevoegd om een mobiele transactie af te wikkelen in Chrome Custom Tabs of Safari View Controler

Veranderingen ten opzichte van versie 1.09

1. Beschrijving toegevoegd over weergavevereisten voor Issuerlijst voor iDIN Ondertekenen

Het transactie proces op een mobiel apparaat is nagenoeg identiek aan het reguliere Transaction Protocol. Het enige verschil is dat er een redirect plaatsvindt naar of de mobiele applicatie van de Issuer of een 'landing page' (gebruik makend van issuerAuthenticationURL) waar de Gebruiker, gebruik makend van zijn mobiele apparaat, kan kiezen om naar de mobiele webpagina of mobiele app van zijn/haar Issuer te worden gestuurd. De issuerAuthenticationURL moet daarom altijd voor uitvoering aan het mobiele OS worden aangeboden of geopend worden met behulp van SafariViewController of Chrome Custom Tabs.

Een RequestedServiceID met bit nummer 13 voor het product type Ondertekenen mag alleen worden aangevraagd bij een Issuer die het product type Ondertekenen heeft geïmplementeerd. De SSP mag alleen een ServiceID aanvragen voor het product type Ondertekenen minimaal bevattende het data attribuut voor BIN (bitnummer 2) en naam (bitnummer 4) om compliance met Verordening (EU) No 910/2014 (eIDAS) te verzekeren.