Versie: 1.1
Datum: 24 Nov 2020 

Voorwaarden

Inhoudsopgave

1. Inleiding

2. Overzicht

Dit hoofdstuk geeft een beschrijving van de algemene elementen in iDIN.

2.1 Het vier-partijen model

Het iDIN systeem is gebaseerd op het vier partijen model. Figuur 1 laat de rollen in dit model zien, vergezeld door hun wederzijdse primaire relaties in de context van iDIN. De rollen zijn die van de Gebruiker, Acceptant, Acquirer (bank van de Acceptant), Issuer (bank van de Gebruiker), Routing Service, Validation Service en Digital Identity Service Providers (DISP):

• Acceptant: De Acceptant is het bedrijf dat de Gebruiker wil identificeren, authentiseren en/of Gebruikersattributen wilt vergaren. Dit kan de daadwerkelijk Acceptant zijn, of een DISP die in naam van de uiteindelijke Acceptant de iDIN-transactie uitvoert;
• Gebruiker: De Gebruiker is een natuurlijk persoon wiens attributen worden beheerd door zijn/haar bank, de Issuer;
• Acquirer: De Acquirer is de bank bij welke de Acceptant zijn contract heeft voor het iDIN product;
• Issuer: De Issuer is de bank van de Gebruiker;
• Routing Service: Dit is een technische rol (routering van berichten) die wordt vervuld door de Acquirer, of door een derde partij die namens de Acquirer handelt. Waar in dit document de term 'Routing Service' wordt gebruikt, dient dit geïnterpreteerd te worden als 'Routing Service van de Acquirer;
• Validation Service: Dit is een technische rol die vervuld wordt door de Issuer of door een derde partij namens de Issuer. Waar in dit document de term 'Validation Service' wordt gebruikt, dient dit geïnterpreteerd te worden als 'Validation Service van de Issuer;
• DISP: Een derde partij die iDIN namens de Acceptant uitvoert als die goedkeuring heeft van zowel de Acceptant en de Acquirer.
  • DISP/Ondertekendienst: Een voor iDIN Ondertekenen gecertificeerde DISP. Binnen het iDIN Scheme noemen we een dergelijke gecertificeerde partij “DISP / Ondertekendienst”, omdat het een bijzondere (sub-)vorm van een DISP is. In de externe communicatie en in de rest van dit document wordt Signing Service Provider (SSP) gebruikt.

2.1.1 De relaties tussen deze rollen

Zowel contractuele als technische relaties bestaan tussen de genoemde rollen. Deze relaties zullen hieronder in meer detail worden toegelicht:

• Acceptant - Acquirer: De Acceptant heeft een contract met de Acquirer;
• Gebruiker - Issuer: De Gebruiker heeft een contract met de Issuer. De identiteit gerelateerd aan dit contract wordt gebruikt voor identificatie, authenticatie, ondertekenen en voor het leveren van Gebruikersattributen;
• Gebruiker - Acceptant: De Gebruiker mag iDIN gebruiken om toegang te krijgen tot een service van de Acceptant;
• Acquirer - Issuer: Gebonden met een licentie binnen het iDIN scheme.

Technische relaties:

• Acceptant - Routing Service: De Acceptant heeft een technische relatie met de Routing Service. De Routing Service biedt de Acceptant de mogelijkheid om verzoeken voor iDIN naar de Validation Service te sturen. In relatie tot dit doel wisselen zij berichten uit;
• Routing Service – Validation Service: De Routing Service en Validation Service hebben een relatie voor het gebruik van iDIN. Ze wisselen in deze context berichten uit;
• Gebruiker – Validation Service: De Validation Service biedt de Gebruiker de mogelijkheid tot het afgeven van authenticatie en/of attributen aan Acceptanten, door het goedkeuren van iDIN verzoeken. De Gebruiker kan een verzoek goedkeuren in de omgeving van zijn/haar Issuer.

2.1.2 Relaties bij gebruik van een DISP of SSP

In het model waar een Acceptant de iDIN activiteiten heeft uitbesteed aan een DISP of SSP is de contract relatie tussen de Acceptant – Acquirer vervangen door de volgende relaties:

• Acceptant - DISP of SSP: De Acceptant heeft een contract met een DISP of SSP;
• DISP of SSP- Acquirer: De DISP of SSP heeft een contract met de Acquirer.

De technische relatie tussen de Acceptant – Routing Service wordt vervangen door de volgende relaties:

• Acceptant - DISP of SSP: De Acceptant heeft een technische relatie met de DISP of SSP. De DISP of SSP levert aan de Acceptant de mogelijkheid om iDIN verzoeken te sturen naar de Routing Service en Validatie Service. In deze context wisselen zij berichten uit;
• DISP of SSP- Routing Service: De DISP of de SSP heeft een technische relatie met de Routing Service. De Routing Service stuurt berichten door van de DISP of de SSP naar de Validation Service. Ze wisselen in deze context berichten uit.

Voor due diligence redenen kunnen er bij de DISP of SSP extra audits worden uitgevoerd. 

2.2 iDIN services

Deze paragraaf introduceert de services die iDIN biedt aan Gebruikers en Acceptanten.
iDIN faciliteert de volgende services:

• Identificatie van de Gebruikers bij de Acceptant gebaseerd op betrouwbare gegevens uitgegeven door de Issuer;
• Leeftijdsverificatie van de Gebruikers bij de Acceptant gebaseerd op betrouwbare gegevens uitgegeven door de Issuer;
• Login van de Gebruikers bij de Acceptant gebaseerd op betrouwbare gegevens uitgegeven door de Issuer;
• Ondertekenen van documenten door Gebruikers met toevoeging van betrouwbare gegevens uitgegeven door de Issuer

Let op: In dit document wordt aan het proces van authenticatie en/of het leveren van Gebruikersattributen gerefereerd als een iDIN-transactie/verzoek.

Bovenstaande services kunnen onder andere door de Acceptant worden gebruikt voor de volgende doeleinden:

• Het aanmaken van nieuwe accounts voor Gebruikers, gebaseerd op gedelegeerde authenticatie en attributen verstrekt door de Issuer;
• Inloggen van bestaande Gebruikers die een account hebben aangemaakt met iDIN, of een bestaande account hebben gekoppeld met iDIN;
• Leeftijdsverificatie.
• Het ondertekenen van documenten door de Gebruiker met iDIN.

Het betrouwbaarheidsnivo voor iDIN is "Substantieel". Dit is bepaald in overeenstemming met de iDIN Rules&Regulations en is gebaseerd op eIDAS EU-verordening 2015 / 1502. De EU-verordening stelt eisen voor onder meer het identificeren van de consument, de authenticatiemiddelen en het gebruik ervan. Deze vereisten zijn opgenomen in de iDIN Rules&Regulations. Dit komt grofweg overeen met het vroegere STORK-betrouwbaarheidsniveau LOA3, dat nog steeds wordt gebruikt in deze technische norm. Het niveau van zekerheid heeft geen betrekking op interoperabiliteit of grensoverschrijdende acceptatie van iDIN.

2.3 iDIN proces

Op de website van de Acceptant start de Gebruiker een iDIN-transactie door allereerst iDIN te selecteren voor inloggen en/of levering van attributen en/of ondertekenen van documenten, en vervolgens zijn/haar Issuer uit de selectielijst te kiezen. De Gebruiker wordt vervolgens doorgestuurd naar de vertrouwde omgeving van zijn/haar Issuer waar het identificatie en authenticatie proces plaatsvindt. Na een succesvolle identificatie en authenticatie kan de Gebruiker de aanvraag van de Acceptant goed- of afkeuren. De Gebruiker wordt vervolgens teruggeleid naar de website van de Acceptant die de aangevraagde authenticatie en/of attributen en/of ondertekening ontvangt .

2.4 iDIN-transactie

Met een iDIN-transactie kan gedelegeerde authenticatie (inloggen), levering van Gebruikersattributen (inclusief leeftijdsverificatie), ondertekenen van documenten of een combinatie worden aangevraagd.

2.4.1 Gedelegeerde authenticatie

Bij de start van een iDIN-transactie kan de Acceptant een unieke, Acceptant specifieke aanduiding van de Gebruiker aanvragen, een Bank Identificatie Nummer (BIN). Dit nummer blijft hetzelfde over meerdere aanvragen mits de Gebruiker bij dezelfde bank inlogt. Dit maakt het voor de Acceptant mogelijk om de aangevraagde BIN te koppelen aan een Gebruiker waarvan de BIN al bekend is in het systeem van de Acceptant. Ook kan de Acceptant een nieuwe account aanmaken (of bestaande account zonder BIN koppelen) om een Gebruiker te koppelen aan een BIN. Bij het goedkeuren van deze aanvraag stemt de Gebruiker in met het inloggen op de website van de Acceptant.

2.4.2 Leveren van Gebruikersattributen

Naast de aanvraag van een BIN kan de Acceptant ook Gebruikersattributen aanvragen. De Gebruiker moet ook voor deze aanvraag altijd expliciete toestemming geven in het domein van zijn/haar bank. Niet alle attributen kunnen individueel worden aangevraagd, de naam- en adresgegevens, het geslacht en de geboortedatum (of leeftijdsverificatie) kunnen wel individueel worden aangevraagd. Zie Sectie 5.3.1 en 5.4 voor meer detail. Doordat de BIN op een andere plek in het SAML bericht zit (namelijk als het onderwerp), wordt het in deze context niet beschouwd als een attribuut. Toestemming vanuit de Gebruiker moet altijd voor alle aangevraagde attributen worden gegeven. De Gebruiker kan dus niet in het domein van zijn/haar Issuer aangeven welke attributen hij/zij wel/niet wil verstrekken. Het is echter voor de Acceptant wel mogelijk, voor het starten van een iDIN-transactie, aan de Gebruiker te vragen welke attributen hij/zij wil verstrekken.

2.5 Acceptant registratie

Als de Acceptant zich registreert voor iDIN verkrijgt deze van zijn Acquirer een Merchant.MerchantID en een Merchant.LegalID dat geassocieerd is met een Merchant.Name. Indien het nodig is krijgt de Acceptant ook een Merchant.SubID voor registratie van één of meer Merchant.TradeName. Dit komt voor als de Acceptant iDIN services gebruikt onder een andere handelsnaam. Alleen de Merchant.MerchantID en Merchant.SubID zijn voor de Acceptant relevant bij het uitvoeren van het iDIN protocol, omdat alleen deze twee waardes nodig voor een succesvolle iDIN-transactie. De andere identificatie elementen worden toegevoegd door de Acquirer en worden alleen in het Acquirer – Issuer domein gebruikt.

2.6 Dispuutmanagement

In het geval van een dispuut moet de Issuer de identiteit van de Gebruiker kunnen leveren. Hiervoor dienen de volgende stappen te worden uitgevoerd:

• De Acceptant moet het originele Security Assertion Markup Language (SAML) iDIN bericht dat de identiteit van de Gebruiker bevat aan zijn Acquirer kunnen leveren. Om te garanderen dat de Issuer de versleutelde berichten kan lezen moet de Acceptant de versleutelde Advanced Encryption Standard (AES) sleutels ontsleutelen met zijn private sleutel. De AES sleutels moeten met het originele bericht worden geleverd.
• De Acquirer moet deze informatie doorsturen naar de Issuer, met contact informatie van de Acceptant;
• De Issuer moet het certificaat van het bericht verifiëren door middel van de elektronische handtekening;
• Door de AES sleutels van de Acceptant te gebruiken kan makkelijk worden geverifieerd of deze ook bij het bericht horen;
• Als het bericht authentiek is moet de Issuer de details van het bericht direct leveren aan de Acceptant en/of de Gebruiker. Het leveren van deze details kan alleen worden gedaan als de Gebruiker zijn/haar goedkeuring heeft gegeven;
• Het geven van deze details wordt gedaan via telefoon:
• De Acquirer moet het telefoonnummer van de Acceptant aan de Issuer geven;
• De Issuer moet de Acceptant op dit nummer bellen om misbruik te voorkomen.

3. iDIN protocollen

Dit hoofdstuk geeft een algemene beschrijving van de iDx protocollen welke als standaard worden gebruikt voor iDIN.

3.1 Technische basisprincipes

• Alle iDIN processen worden geïnitieerd door de Gebruiker op de website van de Acceptant;
• iDIN gebruikt iDx als berichtenstandaard. Binnen deze standaard wordt het generieke container element gebruikt om SAML 2.0 berichten te inbedden, hierin zit informatie die nodig is voor een iDIN-transactie;
• Gebruikers worden aanhoudend geïdentificeerd met behulp van het Bank Identificatie Nummer (BIN), zie Sectie 5.3.1. Dit nummer wordt gegenereerd door de Issuer en is uniek voor elke combinatie Acceptant – Gebruiker bij die betreffende Issuer;
• Een Gebruiker heeft één identiteit per Issuer, onafhankelijk van het aantal accounts;
• De informatie van de Gebruiker wordt in de berichtgeving versleuteld zodat de Routing Service deze informatie niet kan bekijken.

3.2 iDx protocollen

Er zijn vier protocollen die deel uitmaken van iDIN:

• Het Directory Protocol: dit protocol wordt gebruikt om de meest recente lijst van Issuers (bank van de Gebruiker) op te vragen bij de Routing Service.
• Het Transaction Protocol: dit protocol omvat het volledige iDIN proces van initiatie tot voltooiing.
• Het Status Protocol: dit protocol wordt gebruikt om de status van een iDIN-transactie op te vragen bij de Validation Service (via de Routing Service).
• Het Error Protocol: treedt alleen op als response, en wordt gebruikt in het geval dat er iets fout gaat (error).

Een specifieke naam en bijbehorende letter is toegewezen aan elk bericht ter identificatie, zoals gespecificeerd in onderstaande tabel:

Tabel 4: Bericht naamgeving en beschrijving

De volgorde van de protocollen is weergegeven in Figuur 2. De gestippelde lijnen geven berichtgeving aan tussen de Acquirer en Issuer en de Issuer en de Gebruiker. Deze berichtgeving vindt plaats buiten het domein van de Acceptant, maar is weergegeven voor redenen van compleetheid. Om als Acceptant authenticatie en/of Gebruikersattributen te verkrijgen moet zowel het Transaction en Status Protocol worden uitgevoerd. Het Directory Protocol is niet weergegeven, omdat het een simpel request/response bericht is tussen de Acceptant en de Acquirer. Een error bericht kan bij elk request ontstaan en heeft de toevoeging (X) achter de response.

3.2.1 Directory Protocol

Door middel van het Directory Protocol stuurt de Acceptant een DirectoryReq naar de Routing Service. Het DirectoryReq is een verzoek, in XML formaat, van de Acceptant aan de Routing Service om de lijst met aangesloten Issuers op te leveren. De Routing Service levert deze lijst door middel van het DirectoryRes. De banken die de Acceptant in het DirectoryRes ontvangt toont hij aan de Gebruiker. De Gebruiker kiest uit de aangeleverde lijst zijn/haar bank waar hij bankiert aan het begin van het iDIN proces. Het Directoryprotocol wordt in meer detail beschreven in Hoofdstuk 6.

3.2.2 Transaction Protocol

Door middel van het Transaction Protocol stuurt de Acceptant een AcquirerTrxReq naar de Routing Service, waarin o.a. het ID van de door de Gebruiker gekozen Issuer staat, de benodigde iDIN informatie (welke authenticatie en/of Gebruikersattributen wordt aangevraagd) en andere transactiedetails worden doorgegeven. Dit bericht bevat ook de merchantReturnURL die wordt gebruikt om de Gebruiker terug te sturen naar de Acceptant na het afronden van de iDIN-transactie in het bankdomein (redirect). Nadat de Routing Service het bericht van de Acceptant ontvangen heeft, voegt hij de door de Acceptant geregistreerde details toe en stuurt dit door naar de Validation Service die door de Gebruiker is geselecteerd. De Validation Service antwoordt met een bericht dat onder andere de issuerAuthenticationURL bevat. De Routing Service geeft deze issuerAuthenticationURL samen met een uniek Transaction.TransactionID via de AcquirerTrxRes terug aan de Acceptant. Dit is een antwoord op het AcquirerTrxReq.

3.2.2.1  Redirect

De Acceptant dient de Gebruiker nu te redirecten naar de issuerAuthenticationURL, een pagina van het internetbankiersysteem van de Issuer. De Gebruiker komt in zijn/haar internetbankieromgeving terecht waar hij de aanvraag van de Acceptant kan autoriseren. De Gebruiker keurt de iDIN aanvraag goed en ontvangt een bevestiging van zijn/haar bank. Daarna redirect de Issuer de Gebruiker terug naar de website van de Acceptant via de merchantReturnURL. Het Transaction Protocol en de twee redirects worden uitgebreider behandeld in Hoofdstuk 7.

3.2.3 Status Protocol

Als het Transactie Protocol succesvol is afgerond kan de Acceptant het Status Protocol initiëren door een AcquirerStatusReq te versturen naar de Routing Service. De Routing Service vraagt de status van de iDIN-transactie op bij de betreffende Issuer en retourneert deze status aan de Acceptant. Als de gehele iDIN-transactie foutloos is verlopen, ontvangt de Acceptant de informatie van de Gebruiker in de AcquirerStatusRes. In Hoofdstuk 8 is meer informatie te vinden over het Statusprotocol.

3.2.4 Error Protocol

Als er een fout (error) plaatsvindt in één van de bovenstaande protocollen, ontvangt de Acceptant in plaats van een normaal response een AcquirerErrorRes. Dit kan het geval zijn indien een request een error bevat (DirectoryReq, AcquirerTrxReq, AcquirerStatusReq), of als een fout is opgetreden aan de kant van de Acquirer of Issuer. Deze berichten worden in detail beschreven in Hoofdstuk 9.

3.3 SAML V2.0

iDIN gebruikt de iDx standaard voor de berichtgeving. Echter, het generieke container element in het iDx protocol wordt gebruikt om SAML 2.0 te inbedden waarin iDIN specifieke informatie staat. Deze container wordt alleen gebruikt in het AcquirerTrxReq, AcquirerStatusRes en soms in het AcquirerErrorRes (afhankelijk van de type fout die optreedt). Voor alle andere berichten wordt de container weggelaten.

4. iDIN bericht formaat

4.1 Algemeen

Dit hoofdstuk bevat een algemene beschrijving van de bericht structuur voor het Directory, Transaction, Status en Error Protocol. De opeenvolgende secties beschrijven de specifieke velden binnen de XML berichten. Een lijst met data elementen en het formaat van deze elementen kan worden gevonden in de data catalogus in Hoofdstuk 5.
De volgende conventies worden gebruikt om aan te geven of een element in een bericht verplicht is:

• Ja Het element moet precies één keer aanwezig zijn;
• Ja (1..∞) Het element mag één of meerdere malen aanwezig zijn (onbeperkt);
• Nee Het element mag weggelaten worden of mag maximaal één keer aanwezig zijn;
• Nee(0..∞) Het element mag weggelaten worden of mag één of meerdere malen aanwezig zijn (onbeperkt).

4.2 Karakter set

• In alle iDIN berichten moet de Unicode karakterset worden gebruikt. Alleen de MES-2 (Multilingual European Character Set) wordt ondersteund.
• De codering moet worden gebruikt zoals aangegeven in de HTTP en XML headers: UTF-8 (Unicode Transformation Format).
• Het gebruik van karakters die geen onderdeel zijn van de Unicode karakterset zal niet leiden tot een weigering van een verzoek, maar het karakter kan gewijzigd worden naar een spatie, vraagteken of asterisk.
• Het Byte Order Mark (BOM) mag niet worden gebruikt. De UTF-8 representatie van de BOM is de byte sequentie 0xEF,0xBB,0xBF.

4.3 HTTP

• Alle berichten moeten voldoen aan de HTTP 1.1 standaard, gedefinieerd in RFC 2616 van W3C. Voor meer informatie zie: http://www.w3.org/Protocols/rfc2616/rfc2616.html;
• Elk XML request bericht moet worden verzonden binnen het body element van een HTTP POST bericht;
• Elk XML response wordt teruggestuurd binnen het body element van een HTTP 200 OK bericht.

De volgende HTTP header moet worden gebruikt voor alle berichten:

^{Tabel 5: HTTP header}

4.4 XML header

De volgende XML headers moet worden gebruikt voor alle berichten:

^{Tabel 6: XML header}

4.5 XML namespaces

iDIN gebruikt de iDx standaard voor de berichtgeving. Echter, het generieke container element in het iDx protocol wordt gebruikt om SAML 2.0 berichten te inbedden waarin iDIN specifieke informatie staat. Er zijn namespace declaraties voor de iDx berichten en enkele namespace declaraties voor het SAML 2.0 bericht.
De namespaces voor alle berichten zijn als volgt:

^{Tabel 7: iDx namespaces}

De namespace declaraties kan op elke manier worden uitgevoerd die is toegestaan binnen de XML standaard met de paar uitzonderingen zoals wordt vermeld in Sectie 10.3.

4.6 XML Schema's

Alle berichten moeten worden gevalideerd langs de iDIN, SAML 2.0 en W3C schema's. De schema namen en locaties zijn weergegeven in de onderstaande tabel:

^{Tabel 8: XML schema's}

5. iDIN data catalogus

Dit hoofdstuk beschrijft de data elementen en ID's die binnen iDIN worden gebruikt. Als eerste wordt in Sectie 5.1 twee attributen beschreven die alle XML berichten moeten hebben in de root. Alle iDx data elementen zijn beschreven in Sectie 5.2. Vervolgens, in Sectie 5.3 worden de iDIN specifieke data elementen beschreven die specifiek voor iDIN worden gebruikt. Sectie 5.4 geeft alle Gebruikersattributen weer.

5.1 iDx attributen

De volgende twee attributen moeten in de root van elke bericht worden gezet zodat de Acquirer weet welk product (iDIN) en versie wordt gebruikt:

^{Tabel 9: iDx attributen}

5.2 iDx data elementen

iDIN gebruikt de aanduidingen binnen iDx zoals beschreven in Tabel 10. Als het element door de Acceptant moet worden gegenereerd in elk van de requests (DirectoryReq, AcquirerTrxReq, AcquirerStatusReq), dan wordt dat weergegeven in dikgedrukte letters in de beschrijving.

^{Tabel 10: iDx data elementen}

5.3 iDIN data elementen

iDIN gebruikt specifieke data elementen buiten de iDX standaard zoals beschreven in onderstaande tabel. Als het element door de Acceptant moet worden gegenereerd in één van de requests (DirectoryReq, AcquirerTrxReq of AcquirerStatusReq), dan wordt dat weergegeven in dikgedrukte letters in de beschrijving.

^{Tabel 11 Specifieke iDIN data elementen}

5.3.1 iDIN Requested- en DeliveredServiceID

De iDIN services kunnen worden aangevraagd door de Acceptant. Elke transactie request kan alleen een bepaalde set van ID's of attributen leveren van de Gebruiker, gebaseerd op de waarde van het RequestedServiceID. De teruggestuurde Gebruikersinformatie kan verschillen per Issuer, daarom zijn sommige van de attributen die deel uitmaken van een groep optioneel. De Issuer geeft in het teruggestuurde bericht in het element DeliveredServiceID aan welke attributen volgens de minimale set zijn geleverd (zie Sectie 5.5). In de meeste gevallen zal het DeliveredServiceID overeenkomen met het RequestedServiceID. Echter, het kan voorkomen dat de Issuer niet alles wat gevraagd is kan leveren. In dit geval is het RequestedServiceID niet hetzelfde als het DeliveredServiceID. De afhandeling van deze situatie wordt in meer detail besproken in Sectie 12.4.
Met behulp van het Excel '171128A_ServiceID_Calculator' dat bij deze Implementatie Gids wordt verstrekt kan het ServiceID gemakkelijk worden berekend.
Het Requested- en DeliveredServiceID zijn beide integers (een positief heel getal van 0 – 65536) vertaald van een binair formaat (16 bits). Binnen iDIN zijn maar enkele van de mogelijke waardes van het Requested- en DeliveredServiceID gekoppeld aan een valide aanvraag voor Gebruikersattributen. Het binaire nummer is opgesplitst in verschillende groepen. Deze groepen representeren een bepaalde categorie van attributen die de Acceptant mag aanvragen.

Tabel 12 geeft een overzicht welke bits overeenkomen met welke attributen of ID's. De Gebruikersattributen worden behandeld in Sectie 5.4. Als de Acceptant één of meerdere attributen wilt aanvragen kan deze in de onderstaande tabel kijken voor de correcte binaire waardes. Vervolgens moet de vertaling worden gedaan naar een integere waarde.

^{Tabel 12: Overzicht van binaire waardes van Requested- en DeliveredServiceID}
Het RequestedServiceID zit in het SAML request bericht om aan te geven welke attributen de Acceptant aanvraagt. Bijvoorbeeld, als de Acceptant alleen authenticatie wilt doen en de Gebruiker wil inloggen, dan moeten alle binaire waardes nul blijven behalve bit twee, waardoor de waarde van het RequestedServiceID 16384 wordt.

5.4  Gebruikersattributen

De Gebruikersattributen zitten in het SAML 2.0 bericht als resultaat van de aangevraagde service met het BankID.ServiceID. De consumer.bin en consumer.transientid zijn niet gedefinieerd als attributen en zitten daarom in een andere plaats binnen het SAML 2.0 bericht. Waar mogelijk hebben de attributen formatting regels in lijn met de NEN-ISO 8601 standaard. Alle attributen gebruiken de UTF-8 karakter set. iDIN kan de volgende Gebruikersattributen leveren:

^{Tabel 13: Gebruikersattributen}

Notities:

• Gebruikersattributen zitten binnen het SAML Attribute element in het SAML 2.0 bericht. Het @Name geeft aan welk Gebruikersattribuut binnen het element Attribute zit. Het @Name heeft altijd de prefix "nl:bvn:bankid:1.0:attribute:" gevolgd door de naam van het Gebruikersattribuut in kleine letters e.g. "nl:bvn:bankid:1.0:attribute:consumer.city";
• Als één van de attributen langer is dan gespecificeerd in de NEN norm dan wordt deze ingekort en het laatste karakter wordt vervangen door een "-" symbool (zie NEN 1888_2002, p14);
• Sommige Gebruikersattributen zijn niet beschikbaar bij alle Issuers e.g. partnerlastname. In dat geval worden deze waardes door de Issuer weggelaten;

Voorbeeld van een SAML Attribute:

<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.dateofbirth">
     <saml:AttributeValue>19850101</saml:AttributeValue>
</saml:Attribute>

Gegarandeerde minimale set van aangevraagde attributen

Het kan voorkomen dat de Issuer niet alle attributen in de aangevraagde attribuutgroepen kan leveren (die de Acceptant heeft aangegeven te willen ontvangen met het RequestedServiceID). Om deze reden is er een minimale set attributen per attribuutgroep gedefinieerd die de Issuer moet leveren. Alle individueel aangevraagde attributen (e.g. ID's, leeftijd en geslacht) moet de Issuer leveren op aanvraag. Kan de Issuer hier niet aan voldoen dan krijgt de Acceptant alle attributen vanuit de aanvraag die de Issuer wel heeft. Echter wordt aangegeven in het teruggestuurde bericht m.b.v. het DeliveredServiceID en een status code dat niet alle aangevraagde attribuutgroepen voldoen aan de minimale set. Dit wordt in meer detail besproken in Sectie 12.4.

^{Tabel 14: Minimale set attributen per attribuutgroep}

5.5.1 Optioneel de-selecteren en wijzigen van telefoon nr. en emailadres door de Gebruiker

Gebruikers krijgen de optie om hun telefoonnr. en/of emailadres te de-selecteren of te wijzigen als zij de aanvraag goedkeuren bij de Issuer. Dit is alleen mogelijk voor het telefoon en email attribuut, en natuurlijk alleen als de Acceptant deze gegevens aanvraagt.
Als de Gebruiker zijn/haar telefoon en/of email de-selecteert dan wordt dit aan de Acceptant aangegeven in het DeliveredServiceID en in de 2^e SAML StatusCode, zie Sectie 12.4 voor meer details.
Als de Gebruiker zijn/haar telefoon en/of email wijzigt dan wordt dit niet aangegeven aan de Acceptant, immers het attribuut wordt gewoon geleverd. Echter, als het telefoonnummer of emailadres wordt gewijzigd, dan dient dit wel te voldoen aan de formaateisen zoals beschreven is in Tabel 13.

6. iDIN Directory Protocol

6.1 Algemeen

Het Directoryprotocol heeft als doel de Acceptant de actuele lijst met aangesloten Issuers te laten ophalen bij zijn Routing Service, zodat deze lijst getoond kan worden aan de Gebruiker. Het Directory Protocol zorgt ervoor dat wijzigingen in de Issuer lijst automatisch in de keuzelijsten van de Acceptanten worden doorgevoerd.
Het is niet toegestaan het Directory Protocol voor elke iDIN-transactie met een Gebruiker uit te voeren. Aangezien de lijst met Issuers slechts sporadisch wijzigt is het voldoende eenmaal per dag de lijst op te halen en op basis van de directoryDateTimestamp te bepalen of de lijst gewijzigd is. Deze datum specificeert wanneer de Acquirer als laatste de Issuer lijst heeft geüpdatet. De lijst dient, indien deze anders is dan de huidige lijst, opgeslagen te worden en voor alle volgende iDIN-transacties gebruikt te worden. Routing Services informeren normaliter alle Acceptanten (bijv. via e-mail) over wijzigingen in de Issuer lijst. Het Directory Protocol moet minstens eenmaal per week uitgevoerd worden.
Het Directory Protocol bestaat (zoals ook het Transactie Protocol en Status Protocol) uit een HTTP POST request van de Acceptant naar de Routing Service waarop hij een HTTP response ontvangt. Het DirectoryReq wordt verstuurd naar de URL, die door de Routing Service voor dit doel aan de Acceptant is verstrekt. Dit kan een andere URL zijn dan voor het AcquirerTrxReq en AcquirerStatusReq geldt, maar de Routing Service kan hier ook dezelfde URL voor gebruiken.
De Routing Service controleert de authenticiteit van het bericht van de Acceptant door de meegestuurde handtekening te controleren. De Routing Service moet hiervoor beschikken over het gebruikte certificaat van de Acceptant met daarin de publieke sleutel. De manier waarop de Acceptant het publieke deel van het certificaat met de Routing Service deelt verschilt per bank.
In Hoofdstuk 10 staat meer informatie over het controleren van authenticiteit en beveiliging. Appendix B toont een voorbeeld bericht van een DirectoryReq en een DirectoryRes.

6.2 Directory Request (DirectoryReq)

Het DirectoryReq bevat een XML bericht dat naar de Routing Service wordt verstuurd door middel van een HTTP POST. Alle elementen en attributen van het DirectoryReq zijn weergegeven in Tabel 15. De elementen en attributen zijn in het Engels, het element Merchant (Acceptant in Nederlands) bevat informatie van de Acceptant.

^{Tabel 15: Elementen/attributen van het DirectoryReq}

6.3 Directory Response (DirectoryRes)

De Acceptant ontvangt een DirectoryRes als een response van het DirectoryReq (als er geen fout optreedt). Dit XML bericht bevat paarsgewijs Issuer.Name met bijbehorende Issuer.IssuerID. Issuers zijn gegroepeerd per land. De Issuers uit het land van herkomst van de Gebruiker mag aan de top in de lijst van de Issuers worden gepresenteerd, de rest is alfabetisch gesorteerd, eerst bij land, dan bij naam. Alle elementen en attributen van het DirectoryReq zijn weergegeven in Tabel 16.

^{Tabel 16: Elementen/attributen van het DirectoryRes}

6.4 Presentatie van de Issuer selectielijst

Om ervoor te zorgen dat een iDIN-transactie voor de Gebruiker altijd op dezelfde wijze verloopt, dienen alle Acceptant de volgende presentatie aan te houden:
Alle Issuers uit de DirectoryRes moeten worden getoond in een "dropdown listbox". Het eerste element van deze lijst is "Kies uw bank..."; dit is ook het element dat voorgeselecteerd is. Vervolgens wordt de landsnaam van het voorkeursland van de Acceptant getoond (ofwel het land waar de Acceptant is gevestigd ofwel het land waar de Gebruiker (vermoedelijk) vandaan komt). De namen van alle Issuers uit het voorkeursland worden vervolgens getoond in afzonderlijke elementen, in dezelfde (alfabetische) volgorde als gehanteerd in de DirectoryRes. Daarna worden de namen van andere landen en de bijbehorende Issuers getoond, ook weer in dezelfde (alfabetische) volgorde als in de DirectoryRes. De Acceptant moet een foutmelding genereren indien de Gebruiker een van de elementen "Kies uw bank..." of een landsnaam kiest.
Het is aan te bevelen het HTML "value" veld van de items in de listbox in te stellen op de Issuer bankID (BIC) van de betreffende Issuer, omdat deze nodig is in vervolgberichten. Een voorbeeld van een Issuer selectielijst is te vinden in onderstaande figuur:

• Het is de Acceptant niet toegestaan om zelf Issuers (tijdelijk) uit de Issuer selectielijst te verwijderen c.q. uit te grijzen. Een uitzondering wordt gemaakt voor de presentatie van de Issuer selectielijst in het geval van iDIN Ondertekenen. De SSP mag alleen de Issuers aan de consument verstrekken die iDIN Ondertekenen aanbieden. Een lijst van Issuers die het producttype Signature hebben geïmplementeerd, kan worden opgevraagd bij iDIN B.V. (idin@betaalvereniging.nl).
• Indien de Acceptant middels het iDIN Notification System (Centraal Meldpunt voor iDIN banken om onbeschikbaarheid te melden) of via vanuit de Acquirer ontvangen foutmeldingen heeft vastgesteld dat een bepaalde Validation Service niet beschikbaar is, kan de Acceptant een melding tonen aan de Gebruiker op zijn website dat de betreffende Issuer op dat moment niet beschikbaar is. Een dergelijke melding tonen is dus toegestaan; het uitgrijzen of tijdelijk verwijderen van de Issuer uit de Issuer selectielijst is dat niet.

7. iDIN Transaction Protocol

7.1 General

Het Transactie Protocol initieert het berichtenverkeer van het daadwerkelijke iDIN proces. Nadat de Gebruiker voor iDIN als identificatiemethode heeft gekozen en zijn Issuer heeft geselecteerd, stuurt de Acceptant een Transaction Request naar zijn Routing Service. Binnen de standaard wordt dit bericht aangeduid als het AcquirerTrxReq. De Routing Service beantwoordt het AcquirerTrxReq met een AcquirerTrxRes. Deze bevat onder andere de issuerAuthenticationURL waarheen de browser van de Gebruiker moet worden geredirect om de Gebruiker de iDIN-transactie te laten autoriseren.
Het Transaction Protocol bestaat uit een HTTP POST request van de Acceptant naar de Routing Service waarop hij een HTTP response ontvangt. Het AcquirerTrxReq wordt verstuurd naar de URL, die door de Routing Service voor dit doel aan de Acceptant is verstrekt. Dit kan een andere URL zijn die wordt gebruikt voor het DirectoryReq en AcquirerStatusReq, maar de Routing Service kan hier ook dezelfde URL voor gebruiken.
De Routing Service controleert de authenticiteit van het bericht van de Acceptant door de meegestuurde handtekening te controleren. De Routing Service moet hiervoor beschikken over het gebruikte certificaat van de Acceptant met daarin de publieke sleutel. De manier waarop de Acceptant het publieke deel van het certificaat met de Routing Service deelt verschilt per bank.
In Hoofdstuk 10 staat meer informatie over het controleren van authenticiteit en de beveiliging. Appendix B toont een voorbeeld bericht van een AcquirerTrxReq en een AcquirerTrxRes.

7.2 Transaction Request (AcquirerTrxReq)

Het XML bericht dat door de Acceptant naar de Routing Service wordt verstuurd bevat de elementen en attributen zoals weergegeven in Tabel 17. iDIN product specifieke informatie (SAML 2.0 bericht) zit binnen het generieke container element in het AcquirerTrxReq en in de vorm van een SAML 2.0 AuthnRequest, zie Tabel 17.

^{Tabel 17: Elementen/attributen van het AcquirerTrxReq}

Zoals eerder vermeld zit het SAML 2.0 AuthnRequest bericht, dat product specifieke (iDIN) informatie bevat, binnen het generieke container element. Het AuthnRequest bericht is een gestandaardiseerd bericht, en bevat elementen die niet worden gebruikt binnen iDIN, dit is aangegeven in de tabel. Alle elementen en attributen in de container van het AcquirerTrxReq zijn weergegeven in Tabel 17.

^{Tabel 18: Elementen/attributen in de container van het AcquirerTrxReq}

7.3 Transaction Response (AcquirerTrxRes)

Als alles goed gaat reageert de Routing Service op het AcquirerTrxReq met een AcquirerTrxRes. Tabel 19 geeft alle elementen en attributen weer van het AcquirerTrxRes bericht. Het AcquirerTrxRes heeft geen container element, er is dus geen SAML 2.0 bericht in dit response (die is anders indien er sprake is van een Error Response, zie Hoofdstuk 9).

^{Tabel 19: Elementen/attributen van het AcquirerTrxRes}

7.4 Errors (fouten) bij het uitvoeren van het Transactie Protocol

Bij de uitvoering van het Transactie Protocol kunnen een aantal foutsituaties optreden. Deze kunnen te maken hebben met onbeschikbaarheid binnen uw omgeving (Acceptant), of de omgeving van de Routing Service/Validation Service.
De volgende situaties kunnen zich voordoen:

1. Het initiëren van de iDIN-transactie lukt niet.
2. U ontvangt binnen de ingestelde time-out periode een foutbericht (bericht B'(X)) van uw Routing Service.
3. U ontvangt geen bericht binnen de ingestelde time-out periode.

In alle bovenstaande gevallen, kan het Transactie Protocol niet succesvol worden uitgevoerd. Dit betekent dat het niet mogelijk is om een iDIN authenticatie en/of aanvraag Gebruikersattributen uit te voeren. Foutafhandeling wordt in meer detail besproken in Hoofdstuk 9.

7.5 Redirect naar de online bankiersomgeving (issuerAuthenticationURL)

Na het ontvangen van de AcquirerTrxRes dient de Acceptant de Gebruiker door te sturen (redirect) naar de issuerAuthenticationURL van de gekozen bank, zoals die in de AcquirerTrxRes is ontvangen. Als de pagina is opgebouwd met behulp van HTML-frames dan zullen deze door de Issuer verwijderd worden ("frame-busting"). Na terugkomst op de website van de Acceptant (middels de merchantReturnURL) zal de Acceptant ervoor moeten zorgen dat de frames weer opgebouwd worden voor het tonen van de iDIN bevestiging.

7.6 Redirect naar de Acceptant omgeving (merchantReturnURL)

Nadat de Gebruiker de interactie met de Issuer heeft doorlopen, biedt de Issuer hem een 'Doorgaan' knop aan die hem moet terugleiden naar de website van de Acceptant, middels de merchantReturnURL die de Acceptant heeft opgegeven in de AcquirerTrxReq.
Achter deze URL worden twee parameters als GET parameters meegegeven: de entranceCode (zie Sectie 7.2), met als GET parameter naam 'ec' en de Transaction.TransactionID (zie Sectie 7.3), met als GET parameternaam 'trxid'. Het is ook mogelijk voor de Acceptant om andere extra parameters toe te voegen. Als de Acceptant bijvoorbeeld als merchantReturnURL opgeeft: http://www.webwinkel.nl/betaalafhandeling?productsoort=elektronica
kan de uiteindelijke URL er bijvoorbeeld uitzien als: http://www.webwinkel.nl/betaalafhandeling?productsoort=elektronica&trxid=0010123456789012&ec=4hd7TD9wRn76w6gGwGFDgdL7jEtb
Het veld entranceCode dient een unieke waarde te bevatten, om "sniffing" van de berichtuitwisseling tegen te gaan. Kwaadwillenden kunnen door het gebruik van steeds dezelfde entranceCode de gegevens uit de merchantReturnURL onderscheppen, en hier misbruik van maken. Vandaar dat het gebruik van unieke waardes voor de entranceCode van groot belang is.

7.7 Fouten tijdens het uitvoeren van de redirect naar de Issuer, het goedkeuren van de iDIN authenticatie en/of de redirect naar de omgeving van de Acceptant

Bij het uitvoeren van de redirect naar de internetbankiersomgeving (Issuer), het uitvoeren van de iDIN-transactie bij de Issuer en/of de redirect terug naar uw (Acceptant-) omgeving kunnen de volgende foutsituaties zich voordoen:

• De bankpagina is onbereikbaar, waardoor de Gebruiker de iDIN-transactie niet kan goedkeuren, maar ook niet op de juiste manier kan worden teruggeleid naar uw bevestigingspagina;
• De bankpagina is wel bereikbaar maar de Gebruiker kan (na het goedkeuren van de iDIN-transactie, of het annuleren van het proces) niet op de juiste manier worden teruggeleid naar uw bevestigingspagina.

In beide situaties kan de Gebruiker (als gevolg van een storing) dus niet op de normale manier terugkeren naar uw bevestigingspagina. De Gebruiker kan in dat geval bijvoorbeeld via de 'back' knop van zijn browser of door de URL in te tikken terugkomen op uw website. Vanwege de korte geldigheid van de Assertion (30 seconden), is het voor de Merchant aan te raden om een nieuw iDIN-transactie verzoek naar de Acquirer te sturen. De restricties op het aanvragen van de status zijn zo dat de Acceptant alleen een status verzoek mag doen op het moment dat de Gebruiker succesvol is teruggekeerd naar de website van de Acceptant via de meegestuurde merchantReturnURL, zie Sectie 8.5.

7.8 Vier scenario's voor het afronden van het mobiele iDIN proces

Om een overzicht te geven van alle mogelijke processtappen en belangrijke opmerkingen met betrekking tot mobiele iDIN processen, zijn er vier verschillende scenario's gespecificeerd. Er zijn vier verschillende scenario's omdat de Issuer, de Acceptant of beiden gebruik kunnen maken van een (mobiele) webpagina of een mobiele applicatie.
Omdat deze scenario's (kunnen) verschillen van de reguliere (niet-mobiele) iDIN processen, zullen zij worden toegelicht in de volgende secties.

^{Tabel 20: Verschillende scenario's voor de mobiele iDIN processen}

7.9 Verwerkingssnelheid en time-out van transactieberichten

De verwerkingssnelheid van de systemen van de Issuer en de Routing Service heeft een directe invloed op de gebruikerservaring van de Gebruiker. Daarom schrijft iDIN een streeftijd en een time-out periode voor de transactie responseberichten voor. De voor een Acceptant relevante streeftijd en time-out periode hebben betrekking op de communicatie met zijn iDIN Routing Service:

^{Tabel 25: Verwerkingssnelheid eisen (voor het 95ste percentiel} ₇⁾

De streeftijd is de tijd (in seconden) waarbinnen normaal gesproken een AcquirerTrxRes bericht door de Acceptant ontvangen zou moeten zijn na verzending van een AcquirerTrxReq. De time-out is de tijdsduur waarna de Acceptant geen response meer mag verwachten (waarschijnlijk is er een fout opgetreden) en passende actie moet ondernemen (bijvoorbeeld het tonen van een toepasselijke foutmelding aan de Gebruiker).

8. iDIN Status Protocol

8.1 Algemeen

Om na te gaan of een transactie is geslaagd, start de Acceptant het Status Protocol door het versturen van een Status Request naar de Routing Service. In de iDIN Standaard wordt dit bericht aangeduid als het AcquirerStatusReq. Om onnodige belasting van systemen te voorkomen, mogen statusverzoeken niet ongelimiteerd worden gedaan; zie Sectie 8.5 voor meer details over wat is toegestaan. Het statusprotocol mag alleen gestart worden bij terugkeer van de Gebruiker op de website van de Acceptant (na de redirect door de Issuer).

Het Status Protocol bestaat uit een HTTP POST request van de Acceptant naar de Routing Service waarop hij een HTTP response ontvangt. Het AcquirerStatusReq wordt verstuurd naar de URL, die door de Routing Service voor dit doel aan de Acceptant is verstrekt. Dit kan een andere URL zijn dan die wordt gebruikt voor het DirectoryReq en AcquirerTrxReq, maar de Routing Service kan hier ook dezelfde URL voor gebruiken.

De Routing Service controleert de authenticiteit van het bericht van de Acceptant door de meegestuurde handtekening te controleren. De Routing Service moet hiervoor beschikken over het gebruikte certificaat van de Acceptant met daarin de publieke sleutel. De manier waarop de Acceptant het publieke deel van het certificaat met de Routing Service deelt verschilt per bank.

In Hoofdstuk 10 staat meer informatie over het controleren van authenticiteit en beveiliging. Appendix B toont een voorbeeld bericht van een AcquirerStatusReq en een AcquirerStatusRes.

8.2 Status Request (AcquirerStatusReq)

Tabel 26 bevat alle elementen en attributen in het AcquirerStatusReq XML bericht. Het AcquirerStatusReq heeft geen container met daarin een SAML 2.0 bericht.

^{Tabel 26: Elementen/attributen van het AcquirerStatusReq}

8.3 Status Response (AcquirerStatusRes)

De Routing Service reageert met een AcquirerStatusRes als alles goed verloopt. Dit bericht heeft een SAML 2.0 Response binnen het generieke container element dat is gecreëerd door de Issuer en is doorgestuurd via de Routing Service als de transactie is goedgekeurd door de Gebruiker. Het AcquirerStatusRes bevat de elementen en attributen zoals weergegeven in Tabel 27. Dit bericht communiceert de status van de transactie (gerelateerd aan Transaction.TransactionID dat was meegestuurd in het AcquirerStatusReq) aan de Acceptant. Alleen als de status 'Success' is, is er een container element in het AcquirerStatusRes. De elementen en attributen in deze container, als deze aanwezig is, zijn weergegeven in Tabel 28.

^{Tabel 27: Elementen/attributen van het AcquirerStatusRes}

Zoals vermeld zit het SAML 2.0 Response bericht in de generieke container als de status van de transactie 'Success' is. Ook het SAML 2.0 Response bericht is een gestandaardiseerd bericht wat elementen en attributen bevat die niet in de iDIN omgeving worden gebruikt. Het is aan de Validation Service en Routing Service om deze waardes weg te laten, daarom zijn deze niet weergegeven in Tabel 29.

^{Tabel 28: Elementen/attributen in de container van het AcquirerStatusRes}

8.4 Foutsituaties tijdens het uitvoeren van het Statusprotocol

Bij het navragen van de iDIN status door middel van het Status Protocol kunnen foutsituaties optreden waardoor de status van de iDIN-transactie op dat moment niet door u kan worden opgehaald. De eindstatus van de iDIN-transactie kan op dat moment dus niet aan de Gebruiker worden getoond. Aanbevolen berichten die aan de Gebruiker getoond kunnen worden, worden later in dit document gespecificeerd.

8.5 Restricties met betrekking tot AcquirerStatusReq

Een Acceptant mag alleen een AcquirerStatusReq initiëren als:

• De Gebruiker is doorgestuurd naar de Acceptant (E) als onderdeel van het Transaction Protocol.

De SAML Assertion welke uitgegeven is door de Issuer is geldig voor een periode van 30 seconden. Van het moment dat de Gebruiker succesvol is doorgestuurd naar de website van de Acceptant, totdat de Assertion verloopt, kan de Acceptant een status request doen. Meerdere status verzoeken zijn alleen toegestaan als er niet is gereageerd binnen de afgesproken time-out periode. De Acceptant mag, nadat deze een status response heeft ontvangen met een verlopen Assertion, geen status verzoeken doen voor deze specifieke iDIN-transactie, zie Hoofdstuk 9 voor meer informatie.
Acceptanten die het Status Request vaker uitvoeren dan de bovenstaande beschreven limitatie, zullen worden beschouwd als een uitvoerder van ongewenste acties, omdat als ze dit doen er onnodige belasting aan de kant van de Routing Service en Validation Service ontstaat.

8.6 Verwerkingssnelheid en time-out van statusberichten

De verwerkingssnelheid van de systemen van de Issuer en de Routing service heeft een directe invloed op de gebruikerservaring van de Gebruiker. Daarom schrijft iDIN een streeftijd en een time-out periode voor de status responseberichten voor. De voor een Acceptant relevante streeftijd en time-out periode hebben betrekking op de communicatie met zijn iDIN Routing Service:

^{Tabel 29: Verwerkingssnelheid eisen (voor het 95ste percentiel 7)}

De streeftijd is de tijd (in seconden) waarbinnen normaal gesproken een AcquirerStatusRes bericht ontvangen zou moeten zijn door de Acceptant na verzending van een AcquirerStatusReq. De time-out is de tijdsduur waarna de Acceptant geen response meer mag verwachten (waarschijnlijk is er een fout opgetreden) en passende actie moet ondernemen (bijvoorbeeld het tonen van een toepasselijke foutmelding aan de Gebruiker).

9. Foutafhandeling (Error Handling)

9.1 Algemeen

Als er iets fout gaat bij de verwerking van een DirectoryReq, AcquirerTrxReq of AcquirerStatusReq, bijvoorbeeld omdat het request een foutieve waarde bevat, wordt er geen normale response teruggegeven. In plaats daarvan komt er een AcquirerErrorRes bericht terug. Dit bericht heeft dezelfde hoofdstructuur als aangegeven in Tabel 30. De container is alleen in sommige gevallen aanwezig als er een fout optreedt na het versturen van een AcquirerStatusReq.
Appendix B geeft een voorbeeld bericht van een AcquirerErrorRes.

9.2 Error Response (AcquirerErrorRes)

In plaats van een regulier response (DirectoryRes, AcquirerTrxRes or AcquirerStatusRes) kan de Routing Service een AcquirerErrorRes sturen als er een fout is opgetreden in de ontvangst of verwerking van het request, of als er foutieve waardes in het bericht zijn die niet zijn toegestaan of overeenkomen zijn met de iDx/iDIN standaard. Alle elementen en attributen in het AcquirerErrorRes zijn weergegeven in Tabel 30, en de elementen en attributen in de container zijn weergegeven in Tabel 31.

^{Tabel 30: Elementen/attributen van het AcquirerErrorRes}

^{Tabel 31: Elementen/attributen in de container van het AcquirerErrorRes}

9.3 Onbeschikbaarheid

• Het kan zijn dat één van de Issuers tijdelijk niet beschikbaar is. Aanvragen voor die Issuer zullen dan een AcquirerErrorRes opleveren (Sectie 9.2). Nadat een Routing Service heeft vastgesteld dat er sprake is van een onbeschikbaarheid zal hij dit doorgeven aan de betreffende Issuer. Een Acceptant heeft dus nooit rechtstreeks contact met een Issuer.
• Het kan voorkomen dat de Routing Service zelf tijdelijk niet beschikbaar is. In dit geval kunnen er geen iDIN aanvragen worden verwerkt (tenzij de Acceptant meer dan één Routing Service heeft) en levert ieder bericht een AcquirerErrorRes op of een time-out.
• Ook kan het voorkomen dat uw return-webpagina niet goed functioneert. 

In alle drie bovenstaande gevallen adviseren wij u een nette foutmelding te tonen aan de Gebruiker.

10. Beveiliging en certificaten

10.1 Algemene principes van certificaten

Bij asymmetrische encryptie wordt gebruik gemaakt van twee sleutels: een publieke en een private sleutel. De publieke sleutel is gekoppeld aan een certificaat en mag aan iedereen bekend worden gemaakt, de private sleutel moet door de eigenaar strikt geheim worden gehouden. Door bijzondere wiskundige eigenschappen van het private deel en het publieke deel van een certificaat, kan een stuk tekst dat versleuteld (encrypted) is met de publieke sleutel ontsleuteld worden met de private sleutel en vice versa. De RSA sleutels moeten 2048 bits lang zijn. Het is niet mogelijk een tekst te ontsleutelen (decrypted) met dezelfde publieke sleutel als waarmee deze versleuteld is.
Deze bijzondere eigenschappen maken twee toepassingen van certificaten mogelijk:

1. Versleutelen van een bericht. Door een bericht te versleutelen met de publieke sleutel van de ontvanger is de informatie alleen te lezen door de ontvanger (die de private sleutel, die nodig is om te ontsleutelen, als enige kent).
2. Signeren (digitaal ondertekenen) van een bericht. Door (de hash van) een bericht te versleutelen met de private sleutel van de verzender kan de ontvanger (door een succesvolle ontsleuteling met de publieke sleutel van de verzender) vaststellen dat het bericht daadwerkelijk van de verzender komt (authenticiteit) en dat de inhoud van het bericht niet door derden is aangepast (integriteit).

De binnen iDIN gebruikte enkelzijdige Transport Layer Security (TLS) verbinding tussen Acceptant en Routing Service is gebaseerd op de eerste toepassing. Deze TLS verbinding gebruikt 128 bits encryptie waarbij de Routing Service een servercertificaat gebruikt. Acceptanten dienen TLS versie 1.2 of hoger te gebruiken. Oudere versies van TLS zullen in de nabije toekomt niet meer worden ondersteund.
iDIN legt geen eisen op aan de communicatie tussen Acceptant en de Gebruiker. Deze kan al dan niet via TLS verlopen. Acceptanten worden echter aangeraden om altijd TLS te gebruiken voor de authenticatiepagina's van hun website. Binnen iDIN wordt ook gebruik gemaakt van de tweede toepassing, het elektronisch tekenen van een bericht om de authenticiteit, integriteit en onweerlegbaarheid te waarborgen van alle berichten. Doordat bijvoorbeeld de AcquirerStatusRes getekend wordt door de Routing Service kan de Acceptant de iDIN-transactiebevestiging op echtheid controleren.

10.2 Signeren van iDIN berichten

Alle berichten die tussen de Acceptant en Routing service worden verzonden (DirectoryReq, AcquirerTrxReq en AcquirerStatusReq) moeten worden gesigneerd door de Acceptant. Berichten worden gesigneerd volgens de standaard "XML Signature Syntax and Processing", met de volgende instellingen en restricties:

• Het volledige XML bericht XML Signature referentie tot het gesigneerde info URI wordt leeg gelaten. Zei voorbeeld bericht in APPENDIX B moet worden gesigneerd;
• Om de digest voor het volledige bericht te kunnen genereren moet het exclusive canonicalisatie algoritme worden toegepast;
• Om de waarde van de digitale handtekening te kunnen genereren moet het exclusive canonicalisatie algoritme worden toegepast;
• De syntax voor een "enveloped signature" moet gebruikt worden. Voor dit doel moet de handtekening zelf uit het XML bericht worden verwijderd volgens het standaard transformatieproces;
• Voor hashing moet het SHA256 algoritme worden gebruikt.
• Voor digitale handtekening doeleinden moet het RSAWithSHA256 algoritme gebruikt worden. RSA sleutels moeten 2.048 bits lang zijn.
• De publieke sleutel moet gerefereerd worden aan de hand van een fingerprint van een X.509 certificaat. De fingerprint wordt berekend op basis van de volgende formule HEX(SHA-1(DER certificaat)) Zie voorbeeldberichten in APPENDIX B.

In het algemeen hoeft een Acceptant geen diepgaande kennis van RSA te hebben, omdat er voor de meeste (web)programmeertalen libraries bestaan die XML Digital Signature functies implementeren. Het wordt sterk aanbevolen hiervan gebruik te maken.
Standaard functionaliteit voor het aanmaken en verifiëren van RSAWithSHA256 elektronische handtekeningen is voor de veelgebruikte softwareplatformen in elk geval beschikbaar vanaf de volgende versies en hoger:

• PHP 5.5
• Microsoft .NET versie 3.5 sp1
• Java 1.6 u18.

Deze functionaliteit is mogelijkerwijs ook beschikbaar in eerdere versies van genoemde platformen en voor andere platformen (Python, Ruby en anderen).
Voor iDIN zijn Software Libraries ontwikkeld in .NET, PHP en Java. Neem contact op met uw Acquirer voor meer informatie betreffende deze Software Libraries.
Voor het aanmaken van een publieke en private sleutel zie Sectie 10.5.

10.2.1 Signeren van de SAML 2.0 Assertion

Naast de reguliere digitale ondertekening van het totale XML bericht, tekent de Validation Service de SAML 2.0 Assertion apart. Deze Assertion wordt doorgestuurd naar de Acceptant via de Routing Service in het AcquirerStatusRes (alleen als de Transaction.status 'Success' is). Deze digitale handtekening van de SAML 2.0 Assertion heeft dezelfde instellingen en restricties zoals genoemd in de vorige sectie behalve voor het volgende:

• In plaats van een fingerprint te gebruiken om te refereren naar het certificaat van de Issuer wordt het hele certificaat toegevoegd. Het KeyName element wordt vervangen door een X509Data element waarin een X509Certificate element zit wat het volledige certificaat van de Validation Service bevat, zie Tabel 33. Het X509SubjectName element mag worden toegevoegd in het X509Data element. Andere elementen van KeyInfo zullen niet worden gebruikt. Dit is gedaan zodat de Acceptant, die geen relatie heeft met de Validation Service, toch toegang heeft tot het certificaat van de Validation Service om de digitale handtekening te valideren en de attributen te ontsleutelen;
• Het attribuut Reference@URI van de Signature verwijst naar @ID van de Assertion;
• Acceptanten zullen alleen SAML 2.0 berichten vertrouwen en verwerken die zijn gesigneerd met een geldig certificaat van de Validation Service uitgegeven onder de vertrouwde iDIN Issuers.

10.3 SAML EncryptedID en EncryptedAttribute

Voor privacy redenen worden de Gebruikersattributen versleuteld, zodat de Routing Service geen toegang heeft tot leesbare data.

Voor de versleuteling van het EncryptedID en EncryptedAttribute element binnen de SAML 2.0 Assertion gelden de volgende eisen:

• Versleuteling van de Gebruikersattributen wordt gedaan met 256 bit AES sleutels;
  • Deze versleuteling wordt uitgevoerd met het http://www.w3.org/2001/04/xmlenc#aes256-cbc algoritme;
  • Standaard XML padding wordt toegepast +http://www.w3.org/TR/xmlenc-core/#sec-Alg-Block+
• De Validation Service genereert een nieuwe AES sleutel voor elk van de EncryptedAttributes en EncryptedID elementen;
  • De AES sleutels worden versleuteld met de publieke sleutel van de Acceptant;
  • Versleuteling van de AES sleutels wordt uitgevoerd met een RSA algoritme in combinatie met OAEP: http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p;
• De versleutelde EncryptedAttributes en EncryptedID elementen bevatten alle relevante namespace declaraties;
• xsi:type definities mogen worden toegevoegd door de Issuer in het AttributeValue element e.g. <saml:AttributeValue xsi:type="xs:int>.

Het NameID element bevat of de Consumer.BIN of de Consumer.TransientID en is in zijn totaliteit versleuteld (voor de bijbehorende namespaces zie Tabel 7). Een voorbeeld van de versleuteling van een NameID waarin een Consumer.BIN zit is hieronder weergegeven:

<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">%Consumer.BIN%</saml:NameID>

Versleuteling van dit NameID element resulteert in de onderstaande XML code. De %-tekens geven aan welke waarde binnen de elementen moet staan. Het EncryptedKey element, dat de versleutelde AES sleutel bevat, zit ingebed binnen het EncryptedData element.

<saml:EncryptedID
	xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
	<xenc:EncryptedData
		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
Type="http://www.w3.org/2001/04/xmlenc#Element">
		<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
		<ds:KeyInfo
			xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
			<xenc:EncryptedKey Recipient=%Merchant.LegalID%>
				<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
					<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
				</xenc:EncryptionMethod>
				<xenc:CipherData>
					<xenc:CipherValue>%AESKey_Encrypted_With_Public_Key_Merchant%</xenc:CipherValue>
				</xenc:CipherData>
			</xenc:EncryptedKey>
		</ds:KeyInfo>
		<xenc:CipherData>
			<xenc:CipherValue>%NameID_Encrypted_With_AESKey%</xenc:CipherValue>
		</xenc:CipherData>
	</xenc:EncryptedData>
</saml:EncryptedID>

Op dezelfde manier kunnen de Gebruikersattributen worden versleuteld. Het hier onderstaande voorbeeld laat zien hoe de consumer.dateofbirth is versleuteld. Afhankelijk van de vraag van de Acceptant zijn er nul, één of meerdere EncryptedAttribute elementen aanwezig in de SAML 2.0 Assertion.

<saml:Attribute
	xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.dateofbirth">
	<saml:AttributeValue>19850101</saml:AttributeValue>
</saml:Attribute>

Het Attribute wat consumer.dateofbirth bevat is in zijn totaliteit versleuteld tot de volgende XML code:

<saml:EncryptedAttribute
	xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
	<xenc:EncryptedData
		xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Element">
		<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
		<ds:KeyInfo
			xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
			<xenc:EncryptedKey Recipient=%Merchant.LegalID%>
				<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
					<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
				</xenc:EncryptionMethod>
				<xenc:CipherData>
					<xenc:CipherValue>%AESKey_Encrypted_With_Public_Key_Merchant%</xenc:CipherValue>
				</xenc:CipherData>
			</xenc:EncryptedKey>
		</ds:KeyInfo>
		<xenc:CipherData>
			<xenc:CipherValue>%Attribute_Encrypted_With_AES_Key%</xenc:CipherValue>
		</xenc:CipherData>
	</xenc:EncryptedData>
</saml:EncryptedAttribute>

10.4 Authenticatie van iDIN berichten

Om zeker te zijn van de status van een iDIN-transactie, moet de Acceptant de elektronische handtekening van de Routing Service in de response berichten controleren. Ook moet deze de handtekening op de Assertion van de Issuer controleren in het AcquirerStatusRes. Om de handtekening in het SignatureValue element te controleren, wordt aangeraden gebruik te maken van de standaard XML Digital Signature libraries die hiervoor beschikbaar zijn in de meeste (web)programmeertalen.

10.5 Maken van een sleutelpaar

Als u gebruik wilt maken van een zogenaamd "self signed certificate" leest u in deze sectie hoe u dit certificaat kunt maken. U kunt ook een certificaat inkopen bij een daarin gespecialiseerde partij (Certificate Authority), zie daarover de volgende sectie.
Doorloop de volgende stappen om een publieke en geheime sleutel aan te maken:

1. Download de 'OpenSSL Library' van www.openssl.org. Meer informatie over de te gebruiken 'certificate generating utility' vindt u hier: www.openssl.org/docs/apps/req.html. Het is ook mogelijk om met behulp van andere software een sleutelpaar te creëren, raadpleeg in dat geval de handleiding van de gebruikte software.
2. Genereer een 'RSA private key' met het volgende commando (gebruik een zelfgekozen wachtwoord voor het veld [privateKeyPass]):

openssl genrsa –aes128 –out priv.pem –passout pass:[privateKeyPass] 2048

1. Genereer een certificaat op basis van de 'RSA private key' (gebruik hetzelfde wachtwoord voor het veld [privateKeyPass]):

openssl req –x509 –sha256 –new –key priv.pem –passin pass:[privateKeyPass]
-days 1825 –out cert.cer

1. Deze openssl instructie genereert een certificaat in X.509 formaat, met een geldigheid van 5 jaar (1825 dagen), de maximumduur voor iDIN certificaten voor ondertekenen.
2. Het bestand priv.pem bevat de private key, het bestand cert.cer bevat het certificaat met de publieke sleutel. Het bestand priv.pem moet de Acceptant dus zelf houden en wordt gebruikt in de RSA versleuteling. Het cert.cer bestand moet beschikbaar worden gesteld aan de Routing Service. Hoe dit beschikbaar moet worden gesteld, verschilt per Routing Service.

10.5.1 Een certificaat aanschaffen bij een Certificate Authority

Als een certificaat gekocht wordt van een Certificate Authority (CA), in plaats van een self-signed certificaat te gebruiken, is het volgende van belang: Het certificaat dat de CA gebruikt (en de rest van de certificate chain) moet ten minste even veilig zijn als het certificaat van de Acceptant.
CA-certificaten die worden gebruikt om elektronische handtekeningencertificaten te ondertekenen moeten dus ten minste SHA-256 als hashing algoritme gebruiken en RSA sleutels van ten minste 2.048 bits. Certificaten voor ondertekening mogen bovendien maximaal 5 jaar geldig zijn.

10.6 Signature data elementen

Alle berichten, inclusief de Error berichten, zijn ondertekend met een digitale handtekening. De digitale handtekening garandeert de authenticiteit van de zender, integriteit en onweerlegbaarheid van het bericht. De digitale handtekening zit binnen het XML Signature element dat is gedefinieerd volgens de standaard XML-Signature Syntax and Processing, zie Tabel 8 voor de schema locatie. Alle elementen en attributen relevant voor de digitale handtekening in alle iDx en SAML 2.0 berichten zijn hieronder beschreven, andere elementen moeten niet worden gebruikt.

^{Tabel 32: Elementen/attributen van het Signature element}

Het ondertekenen van het SAML 2.0 Assertion wordt anders gedaan. In plaats van te refereren naar het X.509 certificaat d.m.v. een fingerprint wordt het hele certificaat van de Issuer toegevoegd. Bovendien moet het attribuut @URI van Reference verwijzen naar de @ID van de Assertion in plaats van de waarde "" bevatten. Dit leidt tot de vervanging van de inhoud van het KeyInfo element zoals weergegeven in onderstaande tabel, de rest van de elementen en attributen zijn hetzelfde als in Tabel 32:

^{Tabel 33: Veranderingen in de Signature elementen bij ondertekenen van SAML 2.0 Assertion}

11. Presentatie van iDIN

11.1 Algemeen

Ten aanzien van de presentatie van iDIN op de site van de Acceptant geldt een aantal eisen. Het voornaamste doel van deze eisen is het creëren van een uniforme gebruikerservaring, ongeacht op welke website deze iDIN gebruikt. De verschillende eisen worden in de volgende secties genoemd en toegelicht.
De Acceptant draagt primaire verantwoordelijkheid voor het initiëren van het iDIN proces en voor communicatie naar de Gebruiker over de status van het iDIN proces. Acceptanten die iDIN beschikbaar stellen voor hun Gebruikers moeten iDIN in hun bestaande lijst opnemen van authenticatie methoden (als de Acceptant andere methoden aanbiedt). Zodat iDIN op dezelfde wijze wordt gepresenteerd in de lijst als de concurrerende methoden.
Een iDIN-transactie (e.g beginnen van een authenticatie en/of aanvraag Gebruikersattributen) moet altijd ondubbelzinnig door de Gebruiker worden herkend. Dit betekent dat de Acceptant iDIN als dusdanig moet presenteren aan de Gebruiker, dat de selectie en start van een iDIN proces als zodanig herkenbaar is. De Acceptant moet ook duidelijk onderscheid maken tussen de verschillende iDIN processen (authenticatie, leeftijdsverificatie of aanvraag van Gebruikersattributen).

11.2 Transactieflow

Wanneer de Gebruiker een iDIN-transactie start, krijgt de Gebruiker onmiddellijk een Issuer selectielijst gepresenteerd zonder dat er tussenschermen worden getoond door de Acceptant (bv. Gebruiker login en/of registratieschermen). Nadat de relevante Issuer is geselecteerd door de Gebruiker, wordt hij/zij meteen doorgestuurd naar de Issuer bankomgeving van de geselecteerde bank (op basis van de issuerAuthenticationURL die de Acceptant ontvangt in de AcquirerTrxRes).

11.3 Redirect naar de Issuer

Een Acceptant dient de redirect naar de Issuer binnen het browservenster te laten plaatsvinden waar de Gebruiker de Issuer heeft geselecteerd, waarna de volledige pagina van de Acceptant vervangen wordt door de volledige pagina van de gekozen Issuer. Het is dus niet toegestaan de redirect naar de Issuer in een nieuw browservenster te laten plaatsvinden. Het is wel toegestaan een nieuw venster, met zichtbare adresbalk, te openen vóór de Gebruiker zijn bank selecteert.

11.4 Frames

Frames in de site van de Acceptant worden toegestaan. Het scherm van de Issuer zal deze frames wegdrukken met een framebusting techniek zodat de Gebruiker beter kan controleren dat het iDIN proces werkelijk bij zijn/haar Issuer plaats vindt. Na de redirect moet de Acceptant het eigen scherm weer volledig opbouwen, voor het tonen van de bevestiging van het inloggen en/of aanvraag Gebruikersattributen aan de Gebruiker.

11.5 Nieuw venster

Het afhandelen van een iDIN-transactie in een nieuw browservenster is toegestaan, als de Acceptant dit venster laat verschijnen bij (of voorafgaand aan) de authenticatiekeuze door de Gebruiker. Het openen van een nieuw venster mag alleen op initiatief van de Gebruiker gebeuren (geen pop-up). De gehele transactieflow dient in dit venster plaats te vinden tot en met de bevestiging van het iDIN proces door de Acceptant. Dit nieuw geopende venster dient ook voorzien te zijn van een zichtbare adresbalk, zodat dit adres gebruikt kan worden om te controleren of er bij de Issuer een iDIN proces plaatsvindt door verificatie van het adres (URL) en het SSL-certificaat. Gedurende het proces moet het voor de Gebruiker niet mogelijk zijn via het oorspronkelijke browservenster van de Acceptant nogmaals een iDIN proces voor hetzelfde doel te starten.

11.5.1 Specifieke eisen aan iDIN mobiel: Nieuw venster of app

Het mobiele iDIN proces kan een Gebruiker omleiden naar een andere mobiele webpagina of applicatie als onderdeel van de iDIN-transactie. De Acceptant moet ernaar streven om de Gebruiker zoveel mogelijk binnen één browserpagina te houden maar de Acceptant mag geen gebruik maken van een in-app browser (web view) in zijn applicatie (zie Hoofdstuk 7 voor meer details). In die gevallen waar het switchen naar een andere applicatie of venster noodzakelijk is (zoals de redirect naar de Issuer) moet de Gebruiker hierover worden geïnformeerd om verwarring te voorkomen. (Bijvoorbeeld: "U zal nu worden doorgestuurd naar de applicatie of (mobiele) website van uw bank").

11.6 Issuer lijst

De Issuer lijst moet worden gepresenteerd zoals beschreven in Sectie 6.4.

11.7 Banners en logo's

Deze informatie zal beschikbaar worden gemaakt op idin.nl.

11.8 Eisen en aanbeveling iDIN teksten Acceptantschermen

Dit hoofdstuk beschrijft eisen en aanbevelingen van teksten in de Acceptantschermen die aan de Gebruiker worden getoond.

11.8.1 Tonen van de laatste inlog

Als de Gebruiker iDIN gebruikt en heeft ingelogd bij de Acceptant, dan wordt het sterk aangeraden om aan de Gebruiker de datum en tijd tonen van de laatste login (in het algemeen, niet specifiek iDIN), bv. 'De laatste keer dat U bent ingelogd was op 1 Oktober 2015, om 15:41'. De exacte tekst mag door de Acceptant worden bepaald. Dit is zodat de Gebruiker zelf kan controleren of dit tijdstip overeenkomt met zijn/haar laatste bezoek.

11.8.2 Uitleg iDIN aan de Gebruiker

Acceptanten kunnen onderstaande teksten gebruiken om iDIN uit te leggen aan hun klanten.
Uitleg iDIN aan de Gebruiker

• Korte versie: Makkelijk en veilig online identificeren met uw bank.
• Uitgebreide versie (voorkeur): Met iDIN kunt u zich online identificeren bij een bedrijf of instelling. Gemakkelijk, vertrouwd en veilig met de inlogmethode van uw bank.

Uitleg voordelen iDIN aan de Gebruiker

1. Makkelijk en veilig online identificeren.
2. Met de vertrouwde inlogmethode van uw bank.
3. Eén manier van inloggen bij bedrijven en instellingen.
4. Geen aparte gebruikersnamen en wachtwoorden meer onthouden.
5. Zelf invullen van persoonlijke gegevens is niet meer nodig.

11.8.3 Aanbevelingen teksten Acceptantschermen per RequestedServiceID

iDIN biedt verschillende services, die zijn onderverdeeld in de volgende vier product types.
De vier product types zijn als volgt:

1. Gegevens verstrekken/versturen: De Gebruiker kiest ervoor gegevens te verstrekken met iDIN, met of zonder het aanmaken van een account. De Acceptant vraagt deze gegevens op met of zonder BIN. Hieronder valt b.v. ook het verstrekken van de geboortedatum of NAW gegevens met/zonder BIN;
2. Inloggen: De Gebruiker logt in met iDIN. Er worden geen gegevens verstrekt, alleen een BIN;
3. Leeftijd bevestigen: Bevestiging leeftijd 18+ (hierbij wordt het attribuut 18orOlder aangevraagd met of zonder BIN). Dit kan worden gebruikt voor zowel verificatie van leeftijd boven of onder 18 jaar;
4. Ondertekenen: De Gebruiker kiest iDIN om documenten te ondertekenen gebruik maken van de inlogmethode van zijn bank. 

Elke combinatie die gemaakt kan worden met het RequestedServiceID hoort bij één van de vier bovenstaande product types. Appendix A, waar alle waardes van het RequestedServiceID zijn weergegeven, toont ook de bijbehorende product type.
Tabel 34 geeft per product type een aanbeveling van de teksten voor de website van de Acceptant. Het verwijzingsscherm van de Acceptant is het scherm waar de Gebruiker kiest voor het gebruik van iDIN. De return-webpagina is de webpagina van de Acceptant waar de Gebruiker terugkeert nadat deze de transactie heeft goedgekeurd in zijn internetbankieromgeving.

^{Tabel 34: Aanbeveling teksten Acceptantschermen per product type}

11.9 Issuer front-end

Het volgende proces en eisen zijn buiten de scope van de implementatie van de Acceptant, maar zijn toch toegevoegd om een beeld te scheppen van de ervaring van de Gebruiker bij het gebruik van iDIN in het domein van zijn/haar bank.
De Issuer draagt primaire verantwoordelijkheid voor het iDIN proces en voor de communicatie naar de Gebruiker in de omgeving van de Issuer. De pagina volgorde en lay-out (vanaf de redirect van de Acceptant naar de Issuer tot de redirect terug naar de Acceptant) worden bepaald door de Validation Service. Aan de volgende eisen moet worden voldaan:

• Na het selecteren van zijn/haar Issuer op de website van de Acceptant wordt de Gebruiker doorgestuurd naar de Validation Service website. In het actieve browser venster wordt de complete pagina van de Acceptant vervangen door de webpagina van de Validation Service. Als alternatief kan de Validation Service er voor kiezen om automatisch de Gebruiker door te sturen naar de mobiele website of mobiele applicatie van de Issuer. De criteria met betrekking tot wanneer deze automatische redirect plaatsvind wordt overgelaten aan de Validation Service;
  • Optioneel kan de Validation Service de Gebruiker laten kiezen indien de Validation Service meerdere kanalen beschikbaar heeft voor de Gebruiker (e.g. door de Gebruiker te laten kiezen tussen de mobiele webpagina of app). Als deze optie aan de Gebruiker wordt geboden vindt er een tweede redirect plaats naar de authenticatie website of applicatie;
• Ten allen tijde moet het voor de Gebruiker duidelijk zijn dat deze een iDIN-transactie begint. Daarom moet de Validation Service het iDIN logo op elke webpagina/mobiele applicatie laten zien binnen het iDIN proces;
• De Validation Service laat geen informatie zien die niet gerelateerd en irrelevant is voor de iDIN-transactie, en wat de Gebruiker kan afleiden om de iDIN-transactie te voltooien. Informatie die als relevant wordt gezien is:
  • Een help functie die beschikbaar wordt gesteld door de Validation Service waar de Gebruiker extra informatie kan krijgen met betrekking tot de iDIN service(s);
  • Als de Issuer een mobiele applicatie heeft dan mag deze worden aangeboden aan de Gebruiker als download en activatie in het iDIN proces. Let op: downloaden en installeren van deze applicatie kan er voor zorgen dat de expiratieperiode van de transactie verloopt.
• De Validation Service faciliteert alle services van iDIN. De Validation Service moet helder aangegeven aan de Gebruiker voor welke iDIN service de Gebruiker toestemming gaat geven;
• De Validation Service garandeert dat de integriteit en lay-out van de Validation Service webpagina/mobiele applicatie niet verandert als deze de inhoud toont van tekst velden (e.g. door een op malafide Acceptant die kwaadaardige/frauduleuze inhoud verstuurt in de transactie informatie);
• Alle iDIN-transactie gerelateerde informatie (i.e. transactieinformatie, Gebruikersinformatie en Acceptant informatie), moet worden gepresenteerd aan de Gebruiker voor goedkeuring;
• De Gebruiker kan tijdens het iDIN proces of toestemming geven voor het afgeven van alle Gebruikersattributen, of het verzoek in zijn totaliteit weigeren, met de uitzondering van de attributen telefoonnummer en email, zie Sectie 5.5.1 voor meer informatie;
• De Gebruiker is niet toegestaan informatie in de transactie te wijzigen tijdens het iDIN proces, met de uitzondering van de attributen telefoonnummer en email, zie Sectie 5.5.1 voor meer informatie;
• De Validation Service moet duidelijk aan de Gebruiker aangeven hoe deze toestemming kan geven voor de iDIN-transactie;
• De Gebruiker moet al zijn/haar attributen met de bijhorende waardes kunnen zien om een geïnformeerde keuze te maken voor het goedkeuren van de iDIN-transactie. Om deze informatie te verkrijgen moet de Gebruiker eerst inloggen bij de Validation Service. Zodoende kan de Validation Service de Gebruiker authentiseren en de bijhorende informatie aan de Gebruiker tonen;
• De Validation Service geeft duidelijk aan hoe de Gebruiker de transactie kan afbreken;
• Als optie kan de Validation Service een bericht tonen aan de Gebruiker als deze de transactie probeert af te breken door de browser te sluiten, of als deze terug of voorwaarts navigeert door de pijltoetsen in de browser te gebruiken. Dit bericht mag worden getoond omdat dit ongewenst gedrag is binnen de iDIN-transactie. In het bericht kan de Gebruiker worden aangeraden de transactie op een normale manier af te breken of te voltooien;
• De Validation Service is vrij om altijd instructies aan de Gebruiker te tonen die beschrijven hoe de Gebruiker zijn/haar attributen kan wijzigen;
• Als de Validation Service niet aan de minimale set van attributen kan voldoen dan mag deze aan de Gebruiker aangegeven welke attributen missen, en welke stappen moeten worden gedaan om deze informatie aan te vullen. De Validation Service is hierin vrij in keuze en implementatie;
• Na goedkeuring van de iDIN-transactie moet de Gebruiker de optie hebben om onmiddellijk terug te keren naar de website van de Acceptant waar de iDIN-transactie was geïnitieerd. Dit kan worden bereikt door een 'Continue/Akkoord' knop. Het klikken op deze knop redirect de Gebruiker naar de URL van de Acceptant die is meegestuurd naar de Validation Service in de transactie aanvraag.

11.9.1 Teksten op de Issuerschermen per RequestedServiceID

iDIN biedt verschillende services die de Acceptant kan aanvragen met behulp van het RequestedServiceID. Elke service is gekoppeld aan één van drie product types. Afhankelijk van de aangevraagde service zal de Issuer een andere tekst aan de Gebruiker tonen. Tabel 35 toont deze teksten per product type, met de volgende opmerkingen:

• Teksten en termen die altijd door de Issuer worden gebruikt zijn dikgedrukt. Ter illustratie wordt een voorbeeld gegeven, de exacte formulering van de zinnen kan verschillen per bank;
• 'Voor/Inzake Merchant.TradeName' wordt alleen getoond indien deze aanwezig is;
• De verplichte Issuer termen en teksten worden getoond voor en/of na inloggen door de Gebruiker in het Issuerdomein;

De Validation Service toont de attributen van de Gebruiker (bij product type 1 en 3) die zijn aangevraagd door de Acceptant. De Gebruiker kan vervolgens toestemming geven voor het versturen van zijn/haar gegevens aan de Acceptant. 

^{Tabel 35: Termen in Issuerschermen per product type}

De onderstaande screenshot geeft een voorbeeld hoe het goedkeuringsscherm op de website of mobiele applicatie van de Issuer kan worden weergegeven bij het verzoek om gegevens te verstrekken met iDIN.

Appendix A: Foutcodes (Error codes)

Als er iets mis gaat op iDx niveau, dan stuurt de Acquirer een AcquirerErrorRes met een bijbehorende errorCode naar de Acceptant. Als er iets misgaat op SAML niveau dan is deze iDx errorCode gelijk aan AP3000 en zit er een container in het error bericht. Deze container bevat een SAML Response zoals besproken in Sectie 9.2.

iDx error codes

De Error.errorCode is samengesteld uit:

• Een categorie (twee letters)
• Een getal (vier cijfers)

Er wordt onderscheid gemaakt tussen de volgende categorieën:

Tabel 36: Error code categorieën

De volgende iDx error codes bestaan:

^{Tabel 37: Error codes}

Het veld errorDetail in de bovenstaande tabel bevat één van de waardes weergegeven in onderstaande tabel. De schuingedrukte woorden, worden vervangen door daadwerkelijk waardes.

^{Tabel 38: errorDetail}

SAML Error codes

Om aan te geven aan de Acceptant wat er precies fout is gegaan wordt er gebruik gemaakt van het SAML status element, zoals hieronder aangegeven:

<samlp:Status
	xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
	<samlp:StatusCode Name=%Eerste status code%>
		<samlp:StatusCode Name=%Tweede status code% /></samlp:StatusCode>
	<samlp:StatusMessage>Text determined by Routing or Validation Service</samlp:StatusMessage>
</samlp:Status>

SAML definieert twee statuscodes. De eerste status code kan de volgende waardes hebben:

Tabel 39: Eerste SAML statuscodes

De tweede status code is aanwezig voor alle gevallen beschreven in Sectie 9.2. Er zijn enkele standaard SAML codes op dit niveau, en enkele die alleen binnen iDIN worden gebruikt. De mogelijke waardes voor de tweede status code is weergegeven in onderstaande tabel:

^{Tabel 40: Tweede SAML statuscodes}

SAML Error cases

Er zijn twee gevallen waar de eerste SAML status code niet "urn:oasis:names:tc:SAML:2.0:Success" maar "urn:oasis:names:tc:SAML:2.0:Requester" is.

1. Er zit een fout in de container in het AcquirerTrxReq (B): In dit geval wordt een iDx AcquirerErrorRes (B'(X)) teruggestuurd met een SAML Response in de container. De iDx errorCode en errorMessage zijn respectievelijk AP3000 en "Product specific error". De tweede SAML status code is afhankelijk van de type fout.
2. De Acceptant heeft een status verzoek ingediend maar de Assertion is verlopen. Het kan voorkomen dat de Gebruiker de iDIN-transactie heeft goedgekeurd, echter is de Acceptant er niet in geslaagd de status binnen 30 seconden op te vragen. De 30 seconden starten vanaf het moment dat de Gebruiker terug wordt gestuurd naar de website van de Acceptant. In dit geval wordt een AcquirerStatusRes teruggestuurd naar de Acceptant. De iDx status staat op "Success", echter de SAML Response bevat geen attributen maar heeft de opbouw zoals weergegeven in Tabel 31. Hier is de tweede SAML status code gelijk aan "urn:oasis:names:tc:SAML:2.0:status:RequestDenied".

Issuer kan niet alle attributen leveren volgens minimale set of de Gebruiker de-selecteert zijn/haar telefoonnr. of emailadres

Er kan zich de mogelijkheid voordoen dat de Issuer niet alle attributen volgende de minimale set kan leveren. Daarnaast wordt de Gebruiker de mogelijkheid geboden om zijn/haar telefoonnr. en/of emailadres de de-selecteren indien deze zijn aangevraagd door de Acceptant. In dit geval wordt het volgende gedaan:

• Een normaal SAML Response bericht wordt teruggestuurd zoals wordt besproken in Sectie 8.3;
• Indien het telefoonnummer of emailadres zijn ge-de-selecteerd dan worden deze niet geleverd;
• De Issuer levert alle andere attributen die wel beschikbaar zijn gebaseerd op RequestedServiceID;De eerste SAML status code staat gewoon op "urn:oasis:names:tc:SAML:2.0:Success";
• De tweede SAML status code staat op "urn:nl:bvn:bankid:1.0:status:IncompleteAttributeSet";
• Het DeliveredServiceID geeft aan welke attributen wel volgens de minimale set zijn geleverd. Als de Issuer dit niet kan bepalen wordt de waarde '0' gebruikt.

Voorbeeld:

• De Acceptant vraagt de geboortedatum en de attribuutgroep adres met RequestedServiceID 1472;
• De Issuer kan de attribuutgroep adres niet volgens de minimale set leveren (de Issuer heeft de postcode, stad en straatnaam maar heeft geen huisnummer). Hierdoor kan hij geen match maken vanuit de minimale set zoals beschreven in Sectie 5.5;
• De Issuer berekent het DeliveredServiceID dat overeenkomst met de aangevraagde attributen die wel volgens de minimale set kunnen worden geleverd. In dit geval is dit 448, omdat alleen de geboortedatum volledig kan worden geleverd.
• De Issuer levert de geboortedatum en alle attributen uit de (incomplete) groep adres.

Bericht aan de Gebruiker

Het element Error.consumerMessage bevat één van vier gestandaardiseerde teksten die door de Routing Service naar de Acceptant wordt gestuurd, zie Tabel 41. De Acceptant moet de tekst in het element Error.consumerMessage aan de Gebruiker tonen.

^{Tabel 41: Bericht aan de Gebruiker}

Appendix B: Voorbeeld berichten

DirectoryReq (A)

<?xml version="1.0" encoding="UTF-8"?>
<DirectoryReq version="1.0.0" productID="NL:BVN:BankID:1.0"
	xmlns=" http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<createDateTimestamp>2001-12-17T09:30:47.123Z</createDateTimestamp>
	<Merchant>
		<merchantID>1234123456</merchantID>
		<subID>1</subID>
	</Merchant>
	<Signature
		xmlns="http://www.w3.org/2000/09/xmldsig#">
		<SignedInfo>
			<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
			<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
			<Reference URI="">
				<Transforms>
					<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
					<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
				</Transforms>
				<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
				<DigestValue>VW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</DigestValue>
			</Reference>
		</SignedInfo>
		<SignatureValue>
IELLwKSGFMk64US23YrpZ8//hJ8DeJEtYht5knlxJvBOr8dcI+aJTBq+YtyzP9ClcK62Obs5aynHBE/GPHZShuMw+8WHq4fCMInOwKURgwjDOz8UYaIMqG0Ojiz8dFYGn+dH2lL0QVss4jmIIAD8MCijb27oqij6PclXw9Y9veI=
</SignatureValue>
		<KeyInfo>
			<KeyName>7D665C81ABBE1A7D0E525BFC171F04D276F07BF2</KeyName>
		</KeyInfo>
	</Signature>
</DirectoryReq>

DirectoryRes (A')

<?xml version="1.0" encoding="UTF-8"?>
<DirectoryRes version="1.0.0" productID=" NL:BVN:BankID:1.0"
	xmlns=" http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<createDateTimestamp>2001-12-17T09:30:47.123Z</createDateTimestamp>
	<Acquirer>
		<acquirerID>1234</acquirerID>
	</Acquirer>
	<Directory>
		<directoryDateTimestamp>2004-11-10T10:15:12.123Z</directoryDateTimestamp>
		<Country>
			<countryNames>Nederland</countryNames>
			<Issuer>
				<issuerID>BANKNL2U</issuerID>
				<issuerName>Bank 1</issuerName>
			</Issuer>
			<Issuer>
				<issuerID>BANANL2U</issuerID>
				<issuerName>Bank 2</issuerName>
			</Issuer>
			<Issuer>
				<issuerID>BANBNL2UXXX</issuerID>
				<issuerName>Bank 3</issuerName>
			</Issuer>
			<Issuer>
				<issuerID>BANCNL2U</issuerID>
				<issuerName>Bank 4</issuerName>
			</Issuer>
		</Country>
		<Country>
			<countryNames>België/Belgique</countryNames>
			<Issuer>
				<issuerID>BANKBE2U</issuerID>
				<issuerName>Banque 1</issuerName>
			</Issuer>
		</Country>
	</Directory>
	<Signature
		xmlns="http://www.w3.org/2000/09/xmldsig#">
		<SignedInfo>
			<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
			<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
			<Reference URI="">
				<Transforms>
					<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
					<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
				</Transforms>
				<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
				<DigestValue>VW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</DigestValue>
			</Reference>
		</SignedInfo>
		<SignatureValue>
IELLwKSGFMk64US23YrpZ8//hJ8DeJEtYht5knlxJvBOr8dcI+aJTBq+YtyzP9ClcK62Obs5aynHBE/GPHZShuMw+8WHq4fCMInOwKURgwjDOz8UYaIMqG0Ojiz8dFYGn+dH2lL0QVss4jmIIAD8MCijb27oqij6PclXw9Y9veI=
</SignatureValue>
		<KeyInfo>
			<KeyName>7D665C81ABBE1A7D0E525BFC171F04D276F07BF2</KeyName>
		</KeyInfo>
	</Signature>
</DirectoryRes>

AcquirerTrxReq (B)

<?xml version="1.0" encoding="UTF-8"?>
<AcquirerTrxReq version="1.0.0"
productID="NL:BVN:BankID:1.0"
	xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
	<createDateTimestamp>2015-01-01T09:30:00.123Z</createDateTimestamp>
	<Issuer>
		<issuerID>BANKNL2U</issuerID>
	</Issuer>
	<Merchant>
		<merchantID>1234123456</merchantID>
		<subID>1</subID>
		<merchantReturnURL>https://merchantwebsite.nl/returnPage.php?param1=true&param2=3</merchantReturnURL>
	</Merchant>
	<Transaction>
		<expirationPeriod>PT5M</expirationPeriod>
		<language>nl</language>
		<entranceCode>1234567890abcdefghijABCDEFGHIJ1234567890</entranceCode>
		<container>
			<samlp:AuthnRequest
				xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
				xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
AttributeConsumingServiceIndex="21952"
ID="REF1234567890"
IssueInstant="2015-01-01T09:30:00Z"
Version="2.0"
ProtocolBinding="nl:bvn:bankid:1.0:protocol:iDx"
AssertionConsumerServiceURL="https://merchantwebsite.nl/returnPage.php?param1=true&param2=3">
				<saml:Issuer>1234123456</saml:Issuer>
				<samlp:RequestedAuthnContext Comparison="minimum">
					<saml:AuthnContextClassRef>nl:bvn:bankid:1.0:loa3</saml:AuthnContextClassRef>
				</samlp:RequestedAuthnContext>
			</samlp:AuthnRequest>
		</container>
	</Transaction>
	<Signature
		xmlns="http://www.w3.org/2000/09/xmldsig#">
		<SignedInfo>
			<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
			<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
			<Reference URI="">
				<Transforms>
					<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
					<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
				</Transforms>
				<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
				<DigestValue>VW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</DigestValue>
			</Reference>
		</SignedInfo>
	<SignatureValue>IELLwKSGFMk64US23YrpZ8//hJ8DeJEtYht5knlxJvBOr8dcI+aJTBq+YtyzP9ClcK62Obs5aynHBE/GPHZShuMw+8WHq4fCMInOwKURgwjDOz8UYaIMqG0Ojiz8dFYGn+dH2lL0QVss4jmIIAD8MCijb27oqij6PclXw9Y9veI=</SignatureValue>
		<KeyInfo>
			<KeyName>7D665C81ABBE1A7D0E525BFC171F04D276F07BF2</KeyName>
		</KeyInfo>
	</Signature>
</AcquirerTrxReq>

AcquirerTrxRes (B')

<?xml version="1.0" encoding="UTF-8"?>
<AcquirerTrxRes version="1.0.0" productID="NL:BVN:BankID:1.0"
	xmlns=" http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<createDateTimestamp>2001-12-17T09:30:47.123Z</createDateTimestamp>
	<Acquirer>
		<acquirerID>1234</acquirerID>
	</Acquirer>
	<Issuer>
		<issuerAuthenticationURL>https://issuer.nl?param=true&paramRandom=123456789012345678901234567890</issuerAuthenticationURL>
	</Issuer>
	<Transaction>
		<transactionID>1234123456789012</transactionID>
		<transactionCreateDateTimestamp>2001-12-17T09:30:47.123Z</transactionCreateDateTimestamp>
	</Transaction>
	<Signature
		xmlns="http://www.w3.org/2000/09/xmldsig#">
		<SignedInfo>
			<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
			<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
			<Reference URI="">
				<Transforms>
					<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
					<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
				</Transforms>
				<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
				<DigestValue>VW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</DigestValue>
			</Reference>
		</SignedInfo>
		<SignatureValue>
IELLwKSGFMk64US23YrpZ8//hJ8DeJEtYht5knlxJvBOr8dcI+aJTBq+YtyzP9ClcK62Obs5aynHBE/GPHZShuMw+8WHq4fCMInOwKURgwjDOz8UYaIMqG0Ojiz8dFYGn+dH2lL0QVss4jmIIAD8MCijb27oqij6PclXw9Y9veI=
</SignatureValue>
		<KeyInfo>
			<KeyName>7D665C81ABBE1A7D0E525BFC171F04D276F07BF2</KeyName>
		</KeyInfo>
	</Signature>
</AcquirerTrxRes>

AcquirerStatusReq (F)

<?xml version="1.0" encoding="UTF-8"?>
<AcquirerStatusReq version="1.0.0" productID="NL:BVN:BankID:1.0"
	xmlns=" http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<createDateTimestamp>2001-12-17T09:30:47.123Z</createDateTimestamp>
	<Merchant>
		<merchantID>1234123456</merchantID>
		<subID>1</subID>
	</Merchant>
	<Transaction>
		<transactionID>1234123456789012</transactionID>
	</Transaction>
	<Signature
		xmlns="http://www.w3.org/2000/09/xmldsig#">
		<SignedInfo>
			<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
			<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
			<Reference URI="">
				<Transforms>
					<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
					<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
				</Transforms>
				<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
				<DigestValue>VW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</DigestValue>
			</Reference>
		</SignedInfo>
		<SignatureValue>
IELLwKSGFMk64US23YrpZ8//hJ8DeJEtYht5knlxJvBOr8dcI+aJTBq+YtyzP9ClcK62Obs5aynHBE/GPHZShuMw+8WHq4fCMInOwKURgwjDOz8UYaIMqG0Ojiz8dFYGn+dH2lL0QVss4jmIIAD8MCijb27oqij6PclXw9Y9veI=
</SignatureValue>
		<KeyInfo>
			<KeyName>7D665C81ABBE1A7D0E525BFC171F04D276F07BF2</KeyName>
		</KeyInfo>
	</Signature>
</AcquirerStatusReq>

AcquirerStatusRes (F') Unencrypted

<?xml version="1.0" encoding="UTF-8"?>
<AcquirerStatusRes version="1.0.0" productID="NL:BVN:BankID:1.0"
	xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
	<createDateTimestamp>2015-01-01T09:30:47.123Z</createDateTimestamp>
	<Acquirer>
		<acquirerID>1234</acquirerID>
	</Acquirer>
	<Transaction>
		<transactionID>1234123456789012</transactionID>
		<status>Success</status>
		<statusDateTimestamp>2015-01-01T09:30:47.123Z</statusDateTimestamp>
		<container>
			<samlp:Response
				xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="RES-1234123456789012" InResponseTo="REF1234567890" Version="2.0" IssueInstant="2015-01-01T09:30:47.123Z”>
				<saml:Issuer
					xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">1234
				</saml:Issuer>
				<samlp:Status>
					<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success">
						<samlp:StatusCode Value=”urn:nl:bvn:bankid:1.0:status:Success”/></samlp:StatusCode>
				</samlp:Status>
				<saml:Assertion
					xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0" ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant="2015-01-01T09:30:47.123Z”>
					<saml:Issuer>BANKNL2U</saml:Issuer>
					<ds:Signature
						xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
						<ds:SignedInfo>
							<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
							<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
							<ds:Reference URI="#_a75adf55-01d7-40cc-929f-dbd8372ebdfc">
								<ds:Transforms>
									<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
									<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
								</ds:Transforms>
								<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
								<ds:DigestValue>AA+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</ds:DigestValue>
							</ds:Reference>
						</ds:SignedInfo>
						<ds:SignatureValue>AAAAwKSGFMk64US23YrpZ8//hJ8DeJEtYht5knlxJvBOr8dcI+aJTBq+YtyzP9ClcK62Obs5aynHBE/GPHZShuMw+8WHq4fCMInOwKURgwjDOz8UYaIMqG0Ojiz8dFYGn+dH2lL0QVss4jmIIAD8MCijb27oqij6PclXw9Y9veI=</ds:SignatureValue>
						<ds:KeyInfo>
							<ds:X509Data>
								<ds:X509Certificate>MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoTF1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBLSSBTZXJ2ZXIgQ0EgLS0gMjAwMjA3MDFBMB4XDTAyMDcyNjA3Mjc1MVoXDTA2MDkwNDA3Mjc1MVowgYsxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaWNoaWdhbjESMBAGA1UEBxMJQW5uIEFyYm9yMQ4wDAYDVQQKEwVVQ0FJRDEcMBoGA1UEAxMTc2hpYjEuaW50ZXJuZXQyLmVkdTEnMCUGCSqGSIb3DQEJARYYcm9vdEBzaGliMS5pbnRlcm5ldDIuZWR1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZSAb2sxvhAXnXVIVTx8vuRay+x50z7GJjIHRYQgIv6IqaGG04eTcyVMhoekE0b45QgvBIaOAPSZBl13R6+KYiE7x4XAWIrCP+ c2MZVeXeTgV3Yz+USLg2Y+Jh4HxwkPFmZBctyXiUr6DxF8rvoP9W7O27rhRjE pmqOIfGTWQIDAQABox0wGzAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIFoDANBgkq hkiG9w0BAQQFAAOBgQBfDqEW+OI3jqBQHIBzhujN/PizdN7s/z4D5d3pptWDJf2n qgi7lFV6MDkhmTvTqBtjmNk3No7v/dnP6Hr7wHxvCCRwubnmIfZ6QZAv2FU78pLX8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdiowMNTrEG8cCx3w/w==</ds:X509Certificate>
							</ds:X509Data>
						</ds:KeyInfo>
					</ds:Signature>
					<saml:Subject>
						<saml:NameID
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">NLBANKsd45232432663dd34ja8sjsah439h28834HSh23h192h3
						</saml:NameID>
					</saml:Subject>
					<saml:Conditions NotBefore="2015-01-01T09:30:47Z" NotOnOrAfter="2015-01-01T09:31:17.123Z”>
						<saml:AudienceRestriction>
							<saml:Audience>NL69ZZZ123456780000</saml:Audience>
						</saml:AudienceRestriction>
						<saml:OneTimeUse></saml:OneTimeUse>
					</saml:Conditions>
					<saml:AuthnStatement AuthnInstant="2015-01-01T09:30:47.123Z”>
						<saml:AuthnContext>
							<saml:AuthnContextClassRef>nl:bvn:bankid:1.0:loa3</saml:AuthnContextClassRef>
							<saml:AuthenticatingAuthority>BANKNL2U</saml:AuthenticatingAuthority>
						</saml:AuthnContext>
					</saml:AuthnStatement>
					<saml:AttributeStatement>
						<saml:Attribute Name=”urn:nl:bvn:bankid:1.0:bankid.deliveredserviceid">
							<saml:AttributeValue>21952</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.gender">
							<saml:AttributeValue>1</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.legallastname">
							<saml:AttributeValue>Vries</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.preferredlastname">
							<saml:AttributeValue>Vries-Jansen</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.partnerlastname">
							<saml:AttributeValue>Jansen</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.legallastnameprefix">
							<saml:AttributeValue>de</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.preferredlastnameprefix">
							<saml:AttributeValue>de</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.initials">
							<saml:AttributeValue>JV</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.dateofbirth">
							<saml:AttributeValue>19850101</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.street">
							<saml:AttributeValue>Gustav Mahlerplein</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.houseno">
							<saml:AttributeValue>33</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.housenosuf">
							<saml:AttributeValue>bis</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.addressextra">
							<saml:AttributeValue>woonboot t.o. de Albert Heijn</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.postalcode">
							<saml:AttributeValue>1082MS</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.city">
							<saml:AttributeValue>Amsterdam</saml:AttributeValue>
						</saml:Attribute>
						<saml:Attribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:nl:bvn:bankid:1.0:consumer.country">
							<saml:AttributeValue>NL</saml:AttributeValue>
						</saml:Attribute>
					</saml:AttributeStatement>
				</saml:Assertion>
			</samlp:Response>
		</container>
	</Transaction>
	<Signature
		xmlns="http://www.w3.org/2000/09/xmldsig#">
		<SignedInfo>
			<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
			<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
			<Reference URI="">
				<Transforms>
					<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
					<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
				</Transforms>
				<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
				<DigestValue>VW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</DigestValue>
			</Reference>
		</SignedInfo>
		<SignatureValue>IELLwKSGFMk64US23YrpZ8//hJ8DeJEtYht5knlxJvBOr8dcI+aJTBq+YtyzP9ClcK62Obs5aynHBE/GPHZShuMw+8WHq4fCMInOwKURgwjDOz8UYaIMqG0Ojiz8dFYGn+dH2lL0QVss4jmIIAD8MCijb27oqij6PclXw9Y9veI=</SignatureValue>
		<KeyInfo>
			<KeyName>7D665C81ABBE1A7D0E525BFC171F04D276F07BF2</KeyName>
		</KeyInfo>
	</Signature>
</AcquirerStatusRes>

AcquirerStatusRes (F') Encrypted

?xml version="1.0" encoding="UTF-8"?>
<AcquirerStatusRes version="1.0.0" productID="NL:BVN:BankID:1.0"
	xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
	<createDateTimestamp>2015-01-01T09:30:47.123Z</createDateTimestamp>
	<Acquirer>
		<acquirerID>1234</acquirerID>
	</Acquirer>
	<Transaction>
		<transactionID>1234123456789012</transactionID>
		<status>Success</status>
		<statusDateTimestamp>2015-01-01T09:30:47.123Z</statusDateTimestamp>
		<container>
			<samlp:Response
				xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="RES-1234123456789012" InResponseTo="REF1234567890" Version="2.0" IssueInstant="2015-01-01T09:30:47.123Z”>
				<saml:Issuer
					xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">1234
				</saml:Issuer>
				<samlp:Status>
					<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success">
						<samlp:StatusCode Value=”urn:nl:bvn:bankid:1.0:status:Success”/></samlp:StatusCode>
				</samlp:Status>
				<saml:Assertion
					xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0" ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant="2015-01-01T09:30:47.123Z”>
					<saml:Issuer>BANKNL2U</saml:Issuer>
					<ds:Signature
						xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
						<ds:SignedInfo>
							<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
							<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
							<ds:Reference URI="#_a75adf55-01d7-40cc-929f-dbd8372ebdfc">
								<ds:Transforms>
									<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
									<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
								</ds:Transforms>
								<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
								<ds:DigestValue>AA+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</ds:DigestValue>
							</ds:Reference>
						</ds:SignedInfo>
						<ds:SignatureValue>VGhpcyBpcyBhIHRlc3QgbWVzc2FnZSE=</ds:SignatureValue>
						<ds:KeyInfo>
							<ds:X509Data>
								<ds:X509Certificate>MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoTF1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBLSSBTZXJ2ZXIgQ0EgLS0gMjAwMjA3MDFBMB4XDTAyMDcyNjA3Mjc1MVoXDTA2MDkwNDA3Mjc1MVowgYsxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaWNoaWdhbjESMBAGA1UEBxMJQW5uIEFyYm9yMQ4wDAYDVQQKEwVVQ0FJRDEcMBoGA1UEAxMTc2hpYjEuaW50ZXJuZXQyLmVkdTEnMCUGCSqGSIb3DQEJARYYcm9vdEBzaGliMS5pbnRlcm5ldDIuZWR1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZSAb2sxvhAXnXVIVTx8vuRay+x50z7GJjIHRYQgIv6IqaGG04eTcyVMhoekE0b45QgvBIaOAPSZBl13R6+KYiE7x4XAWIrCP+c2MZVeXeTgV3Yz+USLg2Y1on+Jh4HxwkPFmZBctyXiUr6DxF8rvoP9W7O27rhRjE pmqOIfGTWQIDAQABox0wGzAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIFoDANBgkqhkiG9w0BAQQFAAOBgQBfDqEW+OI3jqBQHIBzhujN/PizdN7s/z4D5d3pptWDJf2nqgi7lFV6MDkhmTvTqBtjmNk3No7v/dnP6Hr7wHxvCCRwubnmIfZ6QZAv2FU78pLX8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdiowMNTrEG8cCx3w/w==</ds:X509Certificate>
							</ds:X509Data>
						</ds:KeyInfo>
					</ds:Signature>
					<saml:Subject>
						<saml:EncryptedID
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
							<xenc:EncryptedData
								xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element">
								<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
								<ds:KeyInfo
									xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
									<xenc:EncryptedKey Recipient="NL69ZZZ123456780000">
										<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
											<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
										</xenc:EncryptionMethod>
										<xenc:CipherData>
											<xenc:CipherValue>jenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBsVW+V=</xenc:CipherValue>
										</xenc:CipherData>
									</xenc:EncryptedKey>
								</ds:KeyInfo>
								<xenc:CipherData>
									<xenc:CipherValue>VW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</xenc:CipherValue>
								</xenc:CipherData>
							</xenc:EncryptedData>
						</saml:EncryptedID>
					</saml:Subject>
					<saml:Conditions NotBefore="2015-01-01T09:30:47Z" NotOnOrAfter="2015-01-01T09:31:17.123Z”>
						<saml:AudienceRestriction>
							<saml:Audience>NL69ZZZ123456780000</saml:Audience>
						</saml:AudienceRestriction>
						<saml:OneTimeUse></saml:OneTimeUse>
					</saml:Conditions>
					<saml:AuthnStatement AuthnInstant="2015-01-01T09:30:47.123Z”>
						<saml:AuthnContext>
							<saml:AuthnContextClassRef>nl:bvn:bankid:1.0:loa3</saml:AuthnContextClassRef>
							<saml:AuthenticatingAuthority>BANKNL2U</saml:AuthenticatingAuthority>
						</saml:AuthnContext>
					</saml:AuthnStatement>
					<saml:AttributeStatement>
						<saml:Attribute Name=”urn:nl:bvn:bankid:1.0:bankid.deliveredserviceid">
							<saml:AttributeValue>21952</saml:AttributeValue>
						</saml:Attribute>
						<saml:EncryptedAttribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
							<xenc:EncryptedData
								xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element">
								<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
								<ds:KeyInfo >
									<xenc:EncryptedKey Recipient="NL69ZZZ123456780000">
										<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
											<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
										</xenc:EncryptionMethod>
										<xenc:CipherData>
											<xenc:CipherValue>jenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBsVW+V=</xenc:CipherValue>
										</xenc:CipherData>
									</xenc:EncryptedKey>
								</ds:KeyInfo>
								<xenc:CipherData>
									<xenc:CipherValue>BTeoxDflQ4yfR8KYFvwPVinVPqBsVW+VjenRyZVFCNf=</xenc:CipherValue>
								</xenc:CipherData>
							</xenc:EncryptedData>
						</saml:EncryptedAttribute>
						<saml:EncryptedAttribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
							<xenc:EncryptedData
								xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element">
								<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
								<ds:KeyInfo
									xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
									<xenc:EncryptedKey Recipient="NL69ZZZ123456780000">
										<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
											<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
										</xenc:EncryptionMethod>
										<xenc:CipherData>
											<xenc:CipherValue>jenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBsVW+V=</xenc:CipherValue>
										</xenc:CipherData>
									</xenc:EncryptedKey>
								</ds:KeyInfo>
								<xenc:CipherData>
									<xenc:CipherValue>nVPqBsVW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVi=</xenc:CipherValue>
								</xenc:CipherData>
							</xenc:EncryptedData>
						</saml:EncryptedAttribute>
					</saml:AttributeStatement>
				</saml:Assertion>
			</samlp:Response>
		</container>
	</Transaction>
	<Signature
		xmlns="http://www.w3.org/2000/09/xmldsig#">
		<SignedInfo>
			<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
			<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
			<Reference URI="">
				<Transforms>
					<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
					<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
				</Transforms>
				<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
				<DigestValue>VW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</DigestValue>
			</Reference>
		</SignedInfo>
		<SignatureValue>IELLwKSGFMk64US23YrpZ8//hJ8DeJEtYht5knlxJvBOr8dcI+aJTBq+YtyzP9ClcK62Obs5aynHBE/GPHZShuMw+8WHq4fCMInOwKURgwjDOz8UYaIMqG0Ojiz8dFYGn+dH2lL0QVss4jmIIAD8MCijb27oqij6PclXw9Y9veI=</SignatureValue>
		<KeyInfo>
			<KeyName>7D665C81ABBE1A7D0E525BFC171F04D276F07BF2</KeyName>
		</KeyInfo>
	</Signature>
</AcquirerStatusRes>

AcquirerErrorRes (B'(X))

?xml version="1.0" encoding="UTF-8"?>
<AcquirerStatusRes version="1.0.0" productID="NL:BVN:BankID:1.0"
	xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
	<createDateTimestamp>2015-01-01T09:30:47.123Z</createDateTimestamp>
	<Acquirer>
		<acquirerID>1234</acquirerID>
	</Acquirer>
	<Transaction>
		<transactionID>1234123456789012</transactionID>
		<status>Success</status>
		<statusDateTimestamp>2015-01-01T09:30:47.123Z</statusDateTimestamp>
		<container>
			<samlp:Response
				xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="RES-1234123456789012" InResponseTo="REF1234567890" Version="2.0" IssueInstant="2015-01-01T09:30:47.123Z”>
				<saml:Issuer
					xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">1234
				</saml:Issuer>
				<samlp:Status>
					<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success">
						<samlp:StatusCode Value=”urn:nl:bvn:bankid:1.0:status:Success”/></samlp:StatusCode>
				</samlp:Status>
				<saml:Assertion
					xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0" ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant="2015-01-01T09:30:47.123Z”>
					<saml:Issuer>BANKNL2U</saml:Issuer>
					<ds:Signature
						xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
						<ds:SignedInfo>
							<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
							<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
							<ds:Reference URI="#_a75adf55-01d7-40cc-929f-dbd8372ebdfc">
								<ds:Transforms>
									<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
									<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
								</ds:Transforms>
								<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
								<ds:DigestValue>AA+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</ds:DigestValue>
							</ds:Reference>
						</ds:SignedInfo>
						<ds:SignatureValue>VGhpcyBpcyBhIHRlc3QgbWVzc2FnZSE=</ds:SignatureValue>
						<ds:KeyInfo>
							<ds:X509Data>														<ds:X509Certificate>MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoTF1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBLSSBTZXJ2ZXIgQ0EgLS0gMjAwMjA3MDFBMB4XDTAyMDcyNjA3Mjc1MVoXDTA2MDkwNDA3Mjc1MVowgYsxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaWNoaWdhbjESMBAGA1UEBxMJQW5uIEFyYm9yMQ4wDAYDVQQKEwVVQ0FJRDEcMBoGA1UEAxMTc2hpYjEuaW50ZXJuZXQyLmVkdTEnMCUGCSqGSIb3DQEJARYYcm9vdEBzaGliMS5pbnRlcm5ldDIuZWR1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZSAb2sxvhAXnXVIVTx8vuRay+x50z7GJjIHRYQgIv6IqaGG04eTcyVMhoekE0b45QgvBIaOAPSZBl13R6+KYiE7x4XAWIrCP+c2MZVeXeTgV3Yz+USLg2Y1on+Jh4HxwkPFmZBctyXiUr6DxF8rvoP9W7O27rhRjE pmqOIfGTWQIDAQABox0wGzAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIFoDANBgkqhkiG9w0BAQQFAAOBgQBfDqEW+OI3jqBQHIBzhujN/PizdN7s/z4D5d3pptWDJf2nqgi7lFV6MDkhmTvTqBtjmNk3No7v/dnP6Hr7wHxvCCRwubnmIfZ6QZAv2FU78pLX8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdiowMNTrEG8cCx3w/w==</ds:X509Certificate>
							</ds:X509Data>
						</ds:KeyInfo>
					</ds:Signature>
					<saml:Subject>
						<saml:EncryptedID
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
							<xenc:EncryptedData
								xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element">
								<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
								<ds:KeyInfo
									xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
									<xenc:EncryptedKey Recipient="NL69ZZZ123456780000">
										<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
											<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
										</xenc:EncryptionMethod>
										<xenc:CipherData>
											<xenc:CipherValue>jenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBsVW+V=</xenc:CipherValue>
										</xenc:CipherData>
									</xenc:EncryptedKey>
								</ds:KeyInfo>
								<xenc:CipherData>
									<xenc:CipherValue>VW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</xenc:CipherValue>
								</xenc:CipherData>
							</xenc:EncryptedData>
						</saml:EncryptedID>
					</saml:Subject>
					<saml:Conditions NotBefore="2015-01-01T09:30:47Z" NotOnOrAfter="2015-01-01T09:31:17.123Z”>
						<saml:AudienceRestriction>
							<saml:Audience>NL69ZZZ123456780000</saml:Audience>
						</saml:AudienceRestriction>
						<saml:OneTimeUse></saml:OneTimeUse>
					</saml:Conditions>
					<saml:AuthnStatement AuthnInstant="2015-01-01T09:30:47.123Z”>
						<saml:AuthnContext>
							<saml:AuthnContextClassRef>nl:bvn:bankid:1.0:loa3</saml:AuthnContextClassRef>
							<saml:AuthenticatingAuthority>BANKNL2U</saml:AuthenticatingAuthority>
						</saml:AuthnContext>
					</saml:AuthnStatement>
					<saml:AttributeStatement>
						<saml:Attribute Name=”urn:nl:bvn:bankid:1.0:bankid.deliveredserviceid">
							<saml:AttributeValue>21952</saml:AttributeValue>
						</saml:Attribute>
						<saml:EncryptedAttribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
							<xenc:EncryptedData
								xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element">
								<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
								<ds:KeyInfo >
									<xenc:EncryptedKey Recipient="NL69ZZZ123456780000">
										<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
											<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
										</xenc:EncryptionMethod>
										<xenc:CipherData>
											<xenc:CipherValue>jenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBsVW+V=</xenc:CipherValue>
										</xenc:CipherData>
									</xenc:EncryptedKey>
								</ds:KeyInfo>
								<xenc:CipherData>
									<xenc:CipherValue>BTeoxDflQ4yfR8KYFvwPVinVPqBsVW+VjenRyZVFCNf=</xenc:CipherValue>
								</xenc:CipherData>
							</xenc:EncryptedData>
						</saml:EncryptedAttribute>
						<saml:EncryptedAttribute
							xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
							<xenc:EncryptedData
								xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element">
								<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
								<ds:KeyInfo
									xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
									<xenc:EncryptedKey Recipient="NL69ZZZ123456780000">
										<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
											<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
										</xenc:EncryptionMethod>
										<xenc:CipherData>
											<xenc:CipherValue>jenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBsVW+V=</xenc:CipherValue>
										</xenc:CipherData>
									</xenc:EncryptedKey>
								</ds:KeyInfo>
								<xenc:CipherData>
									<xenc:CipherValue>nVPqBsVW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVi=</xenc:CipherValue>
								</xenc:CipherData>
							</xenc:EncryptedData>
						</saml:EncryptedAttribute>
					</saml:AttributeStatement>
				</saml:Assertion>
			</samlp:Response>
		</container>
	</Transaction>
	<Signature
		xmlns="http://www.w3.org/2000/09/xmldsig#">
		<SignedInfo>
			<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
			<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
			<Reference URI="">
				<Transforms>
					<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
					<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
				</Transforms>
				<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
				<DigestValue>VW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</DigestValue>
			</Reference>
		</SignedInfo>
		<SignatureValue>IELLwKSGFMk64US23YrpZ8//hJ8DeJEtYht5knlxJvBOr8dcI+aJTBq+YtyzP9ClcK62Obs5aynHBE/GPHZShuMw+8WHq4fCMInOwKURgwjDOz8UYaIMqG0Ojiz8dFYGn+dH2lL0QVss4jmIIAD8MCijb27oqij6PclXw9Y9veI=</SignatureValue>
		<KeyInfo>
			<KeyName>7D665C81ABBE1A7D0E525BFC171F04D276F07BF2</KeyName>
		</KeyInfo>
	</Signature>
</AcquirerStatusRes>

Appendix C: iDx Merchant-Acquirer Schema

<?xml version="1.0" encoding="UTF-8"?>
<!-- iDx Messages version 1.0.0: interface Merchant/Acquirer -->
<!-- Copyright © Betaalvereniging -->
<xs:schema
	xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#" targetNamespace="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0.0">
	<xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema.xsd"/>
	<xs:annotation>
		<xs:documentation>elements defined</xs:documentation>
	</xs:annotation>
	<xs:element name="DirectoryReq">
		<xs:annotation>
			<xs:documentation>Directory Request (A)</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="createDateTimestamp" type="dateTime"/>
				<xs:element name="Merchant">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="merchantID" type="Merchant.merchantID"/>
							<xs:element name="subID" type="Merchant.subID"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element ref="ds:Signature"/>
			</xs:sequence>
			<xs:attributeGroup ref="MessageAttributes"/>
		</xs:complexType>
	</xs:element>
	<xs:element name="DirectoryRes">
		<xs:annotation>
			<xs:documentation>Directory Response (A')</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="createDateTimestamp" type="dateTime"/>
				<xs:element name="Acquirer">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="acquirerID" type="Acquirer.acquirerID"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element name="Directory">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="directoryDateTimestamp" type="dateTime"/>
							<xs:element name="Country" maxOccurs="unbounded">
								<xs:complexType>
									<xs:sequence>
										<xs:element name="countryNames" type="Country.countryNames"/>
										<xs:element name="Issuer" maxOccurs="unbounded">
											<xs:complexType>
												<xs:sequence>
													<xs:element name="issuerID" type="Issuer.issuerID"/>
													<xs:element name="issuerName" type="Issuer.issuerName"/>
												</xs:sequence>
											</xs:complexType>
										</xs:element>
									</xs:sequence>
								</xs:complexType>
							</xs:element>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element ref="ds:Signature"/>
			</xs:sequence>
			<xs:attributeGroup ref="MessageAttributes"/>
		</xs:complexType>
	</xs:element>
	<xs:element name="AcquirerTrxReq">
		<xs:annotation>
			<xs:documentation>Acquirer Transaction Request (B)</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="createDateTimestamp" type="dateTime"/>
				<xs:element name="Issuer">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="issuerID" type="Issuer.issuerID"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element name="Merchant">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="merchantID" type="Merchant.merchantID"/>
							<xs:element name="subID" type="Merchant.subID"/>
							<xs:element name="merchantReturnURL" type="url"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element name="Transaction">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="expirationPeriod" type="Transaction.expirationPeriod" minOccurs="0"/>
							<xs:element name="language" type="Transaction.language"/>
							<xs:element name="entranceCode" type="Transaction.entranceCode"/>
							<xs:element name="container" type="Transaction.container"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element ref="ds:Signature"/>
			</xs:sequence>
			<xs:attributeGroup ref="MessageAttributes"/>
		</xs:complexType>
	</xs:element>
	<xs:element name="AcquirerTrxRes">
		<xs:annotation>
			<xs:documentation>Acquirer Transaction Response (B')</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="createDateTimestamp" type="dateTime"/>
				<xs:element name="Acquirer">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="acquirerID" type="Acquirer.acquirerID"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element name="Issuer">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="issuerAuthenticationURL" type="Issuer.issuerAuthenticationURL"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element name="Transaction">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="transactionID" type="Transaction.transactionID"/>
							<xs:element name="transactionCreateDateTimestamp" type="dateTime"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element ref="ds:Signature"/>
			</xs:sequence>
			<xs:attributeGroup ref="MessageAttributes"/>
		</xs:complexType>
	</xs:element>
	<xs:element name="AcquirerStatusReq">
		<xs:annotation>
			<xs:documentation>Acquirer Status Request (F)</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="createDateTimestamp" type="dateTime"/>
				<xs:element name="Merchant">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="merchantID" type="Merchant.merchantID"/>
							<xs:element name="subID" type="Merchant.subID"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element name="Transaction">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="transactionID" type="Transaction.transactionID"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element ref="ds:Signature"/>
			</xs:sequence>
			<xs:attributeGroup ref="MessageAttributes"/>
		</xs:complexType>
	</xs:element>
	<xs:element name="AcquirerStatusRes">
		<xs:annotation>
			<xs:documentation>Acquirer Status Response (F')</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="createDateTimestamp" type="dateTime"/>
				<xs:element name="Acquirer">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="acquirerID" type="Acquirer.acquirerID"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element name="Transaction">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="transactionID" type="Transaction.transactionID"/>
							<xs:element name="status" type="Transaction.status"/>
							<xs:element name="statusDateTimestamp" type="dateTime" minOccurs="0"/>
							<xs:element name="container" type="Transaction.container" minOccurs="0"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element ref="ds:Signature"/>
			</xs:sequence>
			<xs:attributeGroup ref="MessageAttributes"/>
		</xs:complexType>
	</xs:element>
	<xs:element name="AcquirerErrorRes">
		<xs:annotation>
			<xs:documentation>Acquirer Error Response (X')</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="createDateTimestamp" type="dateTime"/>
				<xs:element name="Error">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="errorCode" type="Error.errorCode"/>
							<xs:element name="errorMessage" type="Error.errorMessage"/>
							<xs:element name="errorDetail" type="Error.errorDetail" minOccurs="0"/>
							<xs:element name="suggestedAction" type="Error.suggestedAction" minOccurs="0"/>
							<xs:element name="consumerMessage" type="Error.consumerMessage" minOccurs="0"/>
							<xs:element name="container" type="Transaction.container" minOccurs="0"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element ref="ds:Signature"/>
			</xs:sequence>
			<xs:attributeGroup ref="MessageAttributes"/>
		</xs:complexType>
	</xs:element>
	<xs:annotation>
		<xs:documentation>simpleTypes defined</xs:documentation>
	</xs:annotation>
	<xs:simpleType name="Acquirer.acquirerID">
		<xs:restriction base="xs:token">
			<xs:length value="4" fixed="true"/>
			<xs:pattern value="[0-9]+"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Country.countryNames">
		<xs:restriction base="xs:token">
			<xs:minLength value="1"/>
			<xs:maxLength value="128"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Error.consumerMessage">
		<xs:restriction base="xs:string">
			<xs:maxLength value="512" fixed="true"/>
			<xs:minLength value="1" fixed="true"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Error.errorCode">
		<xs:restriction base="xs:token">
			<xs:length value="6" fixed="true"/>
			<xs:pattern value="[A-Z]{2}[0-9]{4}"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Error.errorDetail">
		<xs:restriction base="xs:string">
			<xs:maxLength value="256" fixed="true"/>
			<xs:minLength value="1" fixed="true"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Error.errorMessage">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="128"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Error.suggestedAction">
		<xs:restriction base="xs:string">
			<xs:maxLength value="512" fixed="true"/>
			<xs:minLength value="1" fixed="true"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Issuer.issuerAuthenticationURL">
		<xs:restriction base="url"/>
	</xs:simpleType>
	<xs:simpleType name="Issuer.issuerID">
		<xs:restriction base="BIC"/>
	</xs:simpleType>
	<xs:simpleType name="Issuer.issuerName">
		<xs:restriction base="xs:token">
			<xs:maxLength value="35" fixed="true"/>
			<xs:minLength value="1" fixed="true"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Merchant.merchantID">
		<xs:restriction base="xs:token">
			<xs:length value="10" fixed="true"/>
			<xs:pattern value="[0-9]+"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Merchant.merchantReturnURL">
		<xs:restriction base="url"/>
	</xs:simpleType>
	<xs:simpleType name="Merchant.subID">
		<xs:restriction base="xs:nonNegativeInteger">
			<xs:maxInclusive value="999999" fixed="true"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Transaction.entranceCode">
		<xs:restriction base="xs:token">
			<xs:minLength value="1" fixed="true"/>
			<xs:maxLength value="40" fixed="true"/>
			<xs:pattern value="[a-zA-Z0-9]+"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Transaction.expirationPeriod">
		<xs:restriction base="xs:duration">
			<xs:minInclusive value="PT1M" fixed="true"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Transaction.language">
		<xs:restriction base="language"/>
	</xs:simpleType>
	<xs:simpleType name="Transaction.status">
		<xs:restriction base="xs:token">
			<xs:pattern value="Open|Success|Failure|Expired|Cancelled|Pending"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Transaction.transactionID">
		<xs:restriction base="xs:token">
			<xs:length value="16" fixed="true"/>
			<xs:pattern value="[0-9]+"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:annotation>
		<xs:documentation>basic simpleTypes defined</xs:documentation>
	</xs:annotation>
	<xs:simpleType name="BIC">
		<xs:restriction base="xs:token">
			<xs:pattern value="[A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="dateTime">
		<xs:restriction base="xs:dateTime">
			<xs:pattern value=".+Z"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="language">
		<xs:restriction base="xs:token">
			<xs:length value="2" fixed="true"/>
			<xs:pattern value="[a-z]+"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="productID">
		<xs:restriction base="xs:string"/>
	</xs:simpleType>
	<xs:simpleType name="url">
		<xs:restriction base="xs:anyURI">
			<xs:maxLength value="512"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="version">
		<xs:restriction base="xs:string">
			<xs:pattern value="1\.0\.0"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:annotation>
		<xs:documentation>complexTypes defined</xs:documentation>
	</xs:annotation>
	<xs:complexType name="Transaction.container">
		<xs:sequence>
			<xs:any namespace="##any" maxOccurs="unbounded"/>
		</xs:sequence>
	</xs:complexType>
	<xs:annotation>
		<xs:documentation>attributeGroups defined</xs:documentation>
	</xs:annotation>
	<xs:attributeGroup name="MessageAttributes">
		<xs:annotation>
			<xs:documentation>attributes of each message</xs:documentation>
		</xs:annotation>
		<xs:attribute name="version" type="version" use="required"/>
		<xs:attribute name="productID" type="productID" use="required"/>
	</xs:attributeGroup>
</xs:schema>