Koppelvlakspecificaties Berichtenbox MijnOverheid

Transcriptie

1 Koppelvlakspecificaties Berichtenbox MijnOverheid Versie 2.1 Datum 25 juli 2016 Status Definitief

2 Colofon Projectnaam MijnOverheid Versienummer 2.1 Contactpersoon Servicecentrum Logius Organisatie Logius Postbus JE Den Haag Bijlage(n) 0 Documentbeheer Datum Versie Auteur Opmerkingen 29 mei Logius Versie 1.40 GEB in Logius-formaat, tekstuele aanpassingen, geen inhoudelijke koppelvlakwijzigingen t.o.v. v oktober oktober Logius - Diverse tekstuele en visuele aanpassingen ter verduidelijking - Toevoeging nieuwe verwerkingscodes Retourbericht - Aanpassing retourbericht Abonnementservice 1.7 Logius Nieuwe specificaties Abonnementservice en berichtenbox- Validatieservice 1.8 Logius Abonnementservice op basis van mutaties toegevoegd. 1.9 Logius Aanpassing n.a.v. laatste release MijnOverheid. 2.0 Logius PDF richtlijnen 2.1 Logius Abonnementservice: VerzoekID optioneel. Aanroepwindow verruimd. Pagina 2 van 37

3 Inhoud Colofon 2 Inhoud 3 1 Inleiding Doelgroep Leeswijzer Referenties 5 2 MijnOverheid Berichtenbox Inleiding Werking van de berichtenbox Uitgangspunten MijnOverheid Berichtenbox 7 3 Techniek van de Berichtenbox Architectuur Transport: Internet / Diginetwerk Digikoppeling PKIoverheid 10 4 Opvragen geabonneerden Berichtenboxvalidatieservice Adressering Operaties Vraagbericht Toelichting op elementen vraagbericht Voorbeeld vraagbericht Antwoordbericht Toelichting op elementen antwoordbericht Voorbeeld antwoordbericht Foutafhandeling Abonnementservice Adressering Operaties Vraagbericht Toelichting op elementen vraagbericht Voorbeeld vraagbericht Antwoordbericht Toelichting op elementen antwoordbericht Voorbeeld antwoordbericht Foutafhandeling 19 5 Aanleveren Berichtenbox-berichten Berichten Verwerkservice Adressering Berichtenbox-bericht 22 Pagina 3 van 37

4 5.1.3 Toelichting op elementen Berichtenbox-batch Voorbeeldbericht Berichtenbox-batch Mapping van Berichtenbox-elementen op webweergave Retourbericht Toelichting op elementen Retourbericht Voorbeeldbericht Retourbericht Toelichting Stadium- en Verwerkingscodes Foutafhandeling Verwerking van batch 30 6 Richtlijnen voor PDF bijlagen PDF/A WCAG 2.0 toegankelijkheidsrichtlijnen PDF compressie 33 7 Afkortingen en begrippen 34 8 Contactgegevens 37 Pagina 4 van 37

5 1 Inleiding Dit document beschrijft de functionele en technische specificaties van de Berichtenbox van MijnOverheid en hoe uw organisatie hiervan gebruik kan maken. Dit document vormt samen met het document Handleiding Aansluiten Berichtenbox een eenheid waarin functioneel, technisch en procedureel wordt beschreven wat aansluiten inhoudt. Voor de laatste versie van dit document, overige documentatie van MijnOverheid en actuele informatie, kijk op: Doelgroep Dit document richt zich op: 1. organisaties met een publieke taak die gebruik willen maken van de Berichtenbox. 2. leveranciers die voor en in opdracht van organisaties met een publieke taak een aansluiting realiseren op de Berichtenbox. 1.2 Leeswijzer Dit document is bruikbaar voor zowel de technische implementatie als het overbrengen van het concept Berichtenbox binnen uw organisatie. Met betrekking tot dit laatste wijzen wij u graag op de fact sheets van MijnOverheid die u kunt vinden op de website van Logius. In paragraaf 2 worden de uitgangspunten voor gebruik van MijnOverheid Berichtenbox beschreven. Paragraaf 3 beschrijft de technische kaders en uitgangspunten, waaronder Digikoppeling, PKI Overheid en Diginetwerk. Paragraaf 4 beschrijft de functionaliteit voor het opvragen van geabonneerden en het aanleveren van berichten staat in paragraaf Referenties Na ontvangst van het aanvraagformulier verstrekt Logius de volgende informatie: - Handleiding Berichtenbox Leveranciersportaal - Handreiking Connectiviteit MijnOverheid - XSD Berichtenbox Berichtverwerkservice.zip - XSD Berichtenbox Abonnementservice.zip - XSD+WSDL Berichtenbox Validatieservice.zip Op de website van Logius ( is veel informatie over MijnOverheid te vinden, waaronder - Aanvraagformulier - Handleiding aansluiten Berichtenbox - Handleiding impactanalyse Berichtenbox - Koppelvlakspecificaties Berichtenbox (dit document) - Checklist testen Berichtenbox Voor informatie over andere relevante overheidsdiensten zie Pagina 5 van 37

6 2 MijnOverheid Berichtenbox 2.1 Inleiding MijnOverheid is de persoonlijke website van burgers voor overheidszaken. Burgers kunnen in MijnOverheid o.a. zien welke gegevens de verschillende organisaties over hen hebben geregistreerd. Burgers kunnen ervoor kiezen om post van de overheid (en van andere organisaties met een publieke taak) digitaal te ontvangen via de Berichtenbox. Een organisatie mag alleen berichten versturen naar burgers die hebben aangegeven berichten van de betreffende organisatie te willen ontvangen. Als burgers een bericht ontvangen, dan krijgen zij daarvan een melding via . De gemeente meldt bijvoorbeeld dat de burger het paspoort moet laten verlengen, of de RDW meldt dat de auto gekeurd moet worden. De privacy van de burger wordt gewaarborgd en overheidsorganisaties voldoen via de Berichtenbox aan hun informatieplicht. Berichten afleveren in de Berichtenbox is te vergelijken met het versturen van aangetekende post. 2.2 Werking van de berichtenbox Organisaties met een publieke taak kunnen op een veilige en betrouwbare wijze elektronisch post versturen naar de Berichtenbox van een burger. Op dit moment is het (net als in de brievenbus thuis) alleen mogelijk om berichten te ontvangen in de Berichtenbox. Burgers hebben zelf niet de mogelijkheid om berichten terug te sturen naar de organisatie. Organisaties geven meestal in het bericht aan hoe burgers op het bericht kunnen reageren. De burger geeft in zijn profiel van MijnOverheid aan van welke (van de aangesloten) organisaties de burger berichten wenst te ontvangen. Als organisatie moet u controleren of een burger een actieve Berichtenbox heeft en zich heeft geabonneerd op uw organisatie (stap 1) voordat berichten worden gestuurd. Na deze controle wordt het digitale bericht verstuurd naar de Berichtenbox van de burger (stap 2). Figuur 1: Procesgang berichtenbox Pagina 6 van 37

7 2.3 Uitgangspunten MijnOverheid Berichtenbox Het versturen van berichten, opvragen van accountstatus en berichtenvoorkeur van een burger verloopt via een beveiligde verbinding tussen de server van uw organisatie en MijnOverheid. Een bericht is persoonlijk en kan maar bij één BSN horen, ongeacht hoe algemeen deze van aard is. Onder gepersonaliseerd bericht wordt verstaan: een bericht met informatie specifiek gericht aan de burger (houder van de betreffende Berichtenbox) en gericht op informatieverstrekking gerelateerd aan een specifieke dienst die de burger bij de betreffende organisatie afneemt. Een burger kan een derde persoon machtigen. Alleen organisaties met een publieke taak zoals overheidsorganisaties, pensioenfondsen, zorgverzekeraars etc. hebben het recht en de mogelijkheid om berichten sturen naar burgers. Een organisatie kan alleen berichten versturen naar burgers die zich hebben geabonneerd op berichten van de betreffende organisatie. Een organisatie moet dit vooraf controleren via de functies van Opvragen geabonneerden. De Berichtenbox is van de Burger. Organisaties (Afnemers) noch Logius hebben niet de mogelijkheid om eenmaal verstuurde berichten uit de Berichtenbox te verwijderen. Organisaties krijgen inzicht of en wanneer berichten zijn afgeleverd (verwerkingsrapport en leveranciersportaal). Organisaties krijgen geen inzicht of en wanneer berichten zijn gelezen. De burger kan, indien een adres is opgegeven in het profiel op MijnOverheid, een notificatie ontvangen wanneer berichten in de Berichtenbox zijn afgeleverd. Na 3 weken volgt een herhaalnotificatie. Aan gebruikers die hun notificatie niet hebben ingeschakeld wordt periodiek een scherm getoond met het advies om dat alsnog te doen. Aan gebruikers die hun notificatie hebben ingeschakeld wordt periodiek een scherm getoond met de vraag of het vastgelegde adres nog actueel is. Vanaf 1 november 2015 heeft iedereen vanaf 14 jaar die Nederlander is of in Nederland woont, een MijnOverheid-account toegewezen. Dit account dient door de burger geactiveerd te worden. Wie niet tot de doelgroep (iedere Nederlander vanaf 14 jaar of in Nederlands woont en over een DigiD beschikt of kan beschikken) behoort, maar vóór 1 november 2015 al een MijnOverheid-account had, behoudt dit voorlopig. Wie niet tot de doelgroep behoort, kan na 1 november niet meer registreren voor MijnOverheid. Alleen aangesloten organisaties hebben het recht om de accountstatus en berichtenvoorkeur van een burger op te vragen. Voor een aansluiting op de Berichtenbox dient de organisatie akkoord te gaan en te voldoen aan de Algemene Voorwaarden van Logius, de preproductie en productie Voorwaarden MijnOverheid en Bewerkersovereenkomst. Voor het uitwisselen van een BSN tussen overheidsorganisaties is geen toestemming van de burger nodig. Er is wel een bewerkersovereenkomst gesloten tussen de overheidorganisatie en Logius. Gebruiksvoorwaarden zijn vastgelegd in een ministeriële Regeling voorzieningen generieke digitale infrastructuur en in de veelgestelde vragen op de website. Een derde partij (intermediair) mag berichten namens een afnemer berichten afleveren bij MijnOverheid. Mits deze organisatie met haar Pagina 7 van 37

8 klant een bewerkersovereenkomst in relatie tot Logius als bewerker heeft getekend. Pagina 8 van 37

9 3 Techniek van de Berichtenbox In deze paragraaf worden de algemene technische kaders geschetst waarbinnen de functies van MijnOverheid en specifiek de Berichtenbox zijn gevormd. 3.1 Architectuur MijnOverheid is onderdeel van de Generieke Digitale Infrastructuur (GDI) en is ontwikkeld binnen de kaders en richtlijnen van de Nederlandse Overheid Referentie Architectuur (NORA). Zie voor meer informatie Figuur 2: Overzicht architectuur MijnOverheid 3.2 Transport: Internet / Diginetwerk Het transport van het berichtenverkeer wordt geregeld via Internet of Diginetwerk. Diginetwerk is het besloten netwerk van de overheid. O.a. Haagse Ring, Suwinet en GEMNET zijn onderdeel van Diginetwerk. Figuur 3: Diginetwerk is het besloten netwerk van de overheid Pagina 9 van 37

10 3.3 Digikoppeling Voor het koppelen van de organisaties aan de Berichtenbox wordt Digikoppeling toegepast. Digikoppeling is een set van standaarden voor berichtenverkeer tussen overheidsorganisaties. Digikoppeling regelt net als een postbode niet de inhoud, maar de logistiek (de envelop) zoals: Wat is het adres waarnaar de serviceaanvraag verstuurd moet worden? Hoe weet de serviceaanbieder wie de aanvrager is? Hoe wordt de inhoud van een bericht beveiligd? Is het bericht goed afgeleverd? MijnOverheid gebruikt twee vormen van berichtenverkeer via Digikoppeling: 1. Bevragingen: een vraag waar direct een reactie op wordt verwacht. Hierbij is snelheid van afleveren belangrijk. Hiervoor wordt het synchrone WUS koppelvlakstandaard gebruikt. 2. Meldingen: men levert een bericht en pas (veel) later komt eventueel een reactie terug. In dit geval is snelheid van afleveren minder belangrijk. Daarentegen is de betrouwbaarheid essentieel, zoals de vraag komt het bericht daadwerkelijk aan (ontvangstbevestiging) of wordt een respons aan de juiste (bijbehorende) vraag gekoppeld?. Hiervoor wordt het asynchrone ebms koppelvlakstandaard gebruikt. Organisaties die aan willen sluiten op MijnOverheid Berichtenbox dienen een Digikoppeling adapter (gateway) te hebben ingericht. Voor meer informatie over het inrichten van een Digikoppeling-adapter en de stappen die genomen moeten worden om aan te sluiten op de Digikoppeling-adapter van de Berichtenbox, zie: PKIoverheid De HTTPS-verbinding (TLS) die tot stand wordt gebracht tussen de Digikoppeling adapter van de aangesloten organisatie en de Digikoppeling adapter van de Berichtenbox is beveiligd met een PKIoverheid-certificaat inclusief Overheidsidentificatienummer (OIN/HRN). Aangezien Digikoppeling 1.0 wordt gebruikt, is het bericht (payload van het ebmsbericht) niet digitaal ondertekend. Voor het controleren van certificaten maakt u gebruikt van de PKIOhierarchie en controleert u de CLR (Certificate Revocation List) Voor meer informatie over PKIoverheid, zie: Voor de stamcertificaten PKIoverheid, zie: Voor een document specifiek gericht op PKIoverheid in combinatie met Digikoppeling, zie Gebruik en achtergrond certificaten : (Fase 1 stap 4) Pagina 10 van 37

11 4 Opvragen geabonneerden Om er zeker van te zijn dat de digitale berichten alleen naar burgers worden verstuurd die in het bezit zijn van een Berichtenbox, dient dit vooraf te worden vastgesteld. Hiervoor zijn twee services beschikbaar: de Berichtenbox Validatieservice (synchroon, WUS, zie paragraaf 4.1) en de Abonnementenservice (Asynchroon, ebms, zie paragraaf 4.2). Voor beide services geldt: Gebruik: deze services controleren welke BSN s een actieve Berichtenbox hebben en hebben aangegeven berichten van uw organisatie te willen ontvangen. Antwoordbericht: de voorkeuren in het antwoordbericht hebben een beperkte actualiteit en zijn niet bedoeld ten behoeve van het kunnen weerleggen dat een bericht voor een BSN (burger) succesvol kan worden verwerkt. Doelbindingsprincipe: Op de geleverde resultaten rust doelbinding. Dat houdt in dat de resultaten niet voor andere doeleinden mogen worden gebruikt, dan met het doel te bepalen of een bericht voor een burger aan de Berichtenbox kan worden aangeboden. Controle: een BSN wordt niet gecontroleerd op geldigheid (bijv. officieel BSN) maar wel op geldigheid van de structuur (bijv. alleen cijfers, maximaal 9 cijfers). Een belangrijk aandachtspunt bij deze services is het feit dat de burger niet de mogelijkheid heeft om per berichttype een voorkeur in zijn profiel vast te leggen. De burger kan alleen op organisatieniveau aangeven of hij berichten wenst te ontvangen van de betreffende organisatie. 4.1 Berichtenboxvalidatieservice Via de webservice Berichtenboxvalidatieservice kan uw organisatie synchroon op basis van een BSN vaststellen of de betreffende burger heeft aangegeven berichten van uw organisatie via de Berichtenbox te willen ontvangen. Aantal BSN s: per bericht mogen maximaal 250 BSN s opgevraagd worden. Indien uw organisatie een groter aantal BSN s wil opvragen moeten meerdere berichten worden verstuurd. Ook kan gebruik worden gemaakt van de Abonnementservice (paragraaf 4.2) Digikoppeling: WUS-berichten worden met dubbelzijdig TLS uitgewisseld met gebruik van een client en server PKIoverheidcertificaat. Authenticatie: Digikoppeling verplicht het gebruik van PKIoverheid-certificaten inclusief Overheidsidentificatienummer (OIN/HRN). Het OIN/HRN uit het bericht wordt vergeleken met het OIN/HRN uit het certificaat Adressering Berichten dienen via een dubbelzijdig TLS transportlaag, versleuteld middels een PKIoverheid-certificaat inclusief OIN, aangeboden te worden. De service ondersteund SOAP tot versie 1.1. De webservicedefinitie is beschreven in een WSDL-bestand, welke opgevraagd wordt via de endpoints (met toevoeging van?wsdl ). De endpoints beschrijven de locatie waar het SOAP-bericht naar gestuurd moet worden. De endpoints Pagina 11 van 37

12 worden door Logius verstrekt na ontvangst van het Aanvraagformulier in de handreiking connectiviteit Operaties De webservice definieert de volgende operatie: ValidateAbonnementen Deze operatie geeft voor een set van BSN s (één tot maximaal 250 burgers) aan of deze een bericht van uw organisatie willen ontvangen in hun Berichtenbox. Alle opgegeven BSN s worden teruggestuurd in dezelfde volgorde waarin ze zijn aangeboden. Voor deze operatie geldt dat een actief BerichtTypeCode meegegeven moet worden, deze dient aangemaakt te worden in het Berichtenbox Leveranciersportaal Vraagbericht Het vraagbericht wat uw organisatie in het SOAP-bericht moet plaatsen heeft de volgende structuur: Figuur 4: Structuur vraagbericht Berichtenboxvalidatieservice Toelichting op elementen vraagbericht Element BerichtLeverancierCode BerichtTypeCode Klanten Key Toelichting Het OIN van uw organisatie, 20 cijfers. Aanduiding van het BerichtType dat uw organisatie wilt verzenden. De codes worden door uw organisatie zelf toegekend via het Berichtenbox Leveranciersportaal. Lijst van Klant-elementen. Één tot maximaal 250 BSN s per vraagbericht.* Het BSN van de burger. De combinatie Key en Rol vormt een unieke identificatie. Een BSN mag voorloop nul(len) bevatten. Rol Vaste waarde: Burger. * Indien uw organisatie een groter aantal BSN s wil opvragen moeten meerdere berichten worden verstuurd Voorbeeld vraagbericht <soapenv:envelope xmlns:soapenv=" xmlns:ns=" xmlns:ns1=" xmlns:ns2=" <soapenv:header/> <soapenv:body> <ns:validateabonnementen> <ns:validateabonnementenaanvraag> <ns1:berichtleveranciercode> </ns1:berichtleveranciercode> <ns1:berichttypecode>apk00001</ns1:berichttypecode> <ns1:klanten> <ns2:klant> Pagina 12 van 37

13 <ns2:key> </ns2:key> <ns2:rol>burger</ns2:rol> </ns2:klant> </ns1:klanten> </ns:validateabonnementenaanvraag> </ns:validateabonnementen> </soapenv:body> </soapenv:envelope> Antwoordbericht In de verbinding die opgezet is vanuit uw organisatie bij het versturen van het vraagbericht volgt direct het antwoordbericht (synchroon, conform Digikoppeling-WUS) en heeft de volgende structuur: Figuur 5: Structuur antwoordbericht Berichtenboxvalidatieservice Toelichting op elementen antwoordbericht Element ValidateAbonnementenResult Klant isberichtsturen Toelichting Lijst van de bevraagde klanten uit het vraagbericht opgenomen in Abonnement-element. Één tot maximaal 250 per vraag en antwoordbericht. Idem vraagbericht. Boolean (true of false) welke aangeeft of uw organisatie een bericht (van het opgegeven BerichtType) naar de Berichtenbox van deze burger mag sturen Voorbeeld antwoordbericht <soapenv:envelope xmlns:soapenv=" xmlns:ns=" xmlns:ns1=" xmlns:ns2=" <soapenv:header/> <soapenv:body> <ns:validateabonnementenresponse> <ns:validateabonnementenresult> <ns1:abonnement> <ns1:klant> <ns2:key> </ns2:key> <ns2:rol>burger</ns2:rol> </ns1:klant> <ns1:isberichtsturen>true</ns1:isberichtsturen> </ns1:abonnement> </ns:validateabonnementenresult> </ns:validateabonnementenresponse> </soapenv:body> </soapenv:envelope> Foutafhandeling Indien er een fout optreedt bij de verwerking van het vraagbericht, wordt een foutbericht teruggegeven. Pagina 13 van 37

14 <s:envelope xmlns:a=" xmlns:s=" <s:body> <s:fault> <faultcode>s:client</faultcode> <faultstring xml:lang="nl-nl">klantkey is leeg. Parameter name: validateabonnementenaanvraag</faultstring> <detail> <ApplicationFault xmlns:i= xmlns=" <Message>Klantkey is leeg. Parameter name: validateabonnementenaanvraag </Message> </ApplicationFault> </detail> </s:fault> </s:body> </s:envelope> Een ander foutbericht ziet er als volgt uit: <env:envelope xmlns:env=" <env:body> <env:fault> <faultcode>env:client</faultcode> <faultstring>internal Error (from client)</faultstring> </env:fault> </env:body> </env:envelope> 4.2 Abonnementservice Via de Abonnementservice kan uw organisatie asynchroon op basis van een BSN vaststellen of de betreffende burger heeft aangegeven berichten van uw organisatie via de Berichtenbox te willen ontvangen. Aanroep frequentie: de service mag maximaal één keer per dag worden aangesproken. De service mag alleen 's nachts (tussen en 7.00 uur) worden aangeroepen. Reactietijd: Het antwoord wordt in de vorm van een melding gegeven, er is sprake van asynchrone communicatie. Het antwoord wordt binnen 4 uur gegeven. Compressie: het antwoordbericht (payload van ebms-bericht) bevat XML-gegevens waarop een Gzip operatie 1 is toegepast. Hiermee wordt de hoeveelheid te versturen gegevens beperkt, naar schatting is de omvang van het gecomprimeerde bericht slechts 10% van de omvang van het originele bericht. Varianten: De abonnementservice kent drie varianten, zie onder. Transport ebms: Digikoppeling: ebms-berichten worden met dubbelzijdig TLS uitgewisseld met behulp van een PKIoverheid-certificaat. Voor ebms wordt een CPA contract opgesteld waarin het cliënt en server certificaat van Service Requester (uw organisatie) en Service Provider (Berichtenbox MijnOverheid) is opgenomen. Er is slechts 1 CPA benodigd om zowel een abonneevraag-bericht als berichtenbox-verwerkservice aan te leveren en een retourbericht te ontvangen. Authenticatie: Digikoppeling verplicht het gebruik van PKIoverheid-certificaten inclusief Overheidsidentificatienummer (OIN/HRN). Het OIN/HRN uit het bericht wordt vergeleken met het OIN/HRN uit het CPA. 1 Volgens het algoritme dat is beschreven in RFC 1952, zie: Pagina 14 van 37

15 De abonnementservice kent drie varianten. Variant 1 BSN lijst : Uw organisatie stuurt een vraagbericht met daarin opgenomen maximaal 1 miljoen BSN s. De abonnementservice retourneert van deze selectie de BSN s met een actieve Berichtenbox waarbij de burger heeft aangegeven berichten te willen ontvangen uw organisatie. Varianten 2 volledig : Uw organisatie verstuurt een vraagbericht zonder daarin BSN s op te nemen. U ontvangt daarop alle BSN s bekent binnen MijnOverheid waarvoor geldt dat er een actieve berichtenbox is en waarvan de burger heeft aangegeven berichten te willen ontvangen van uw organisatie. Het retourbericht bevat mogelijk meer BSN s dan waarvoor uw organisatie een relatie mee heeft. Variant 3 mutaties : Uw organisatie verstuurt een vraagbericht met hierin een mutatiedatum/tijd. Alle mutaties op berichtvoorkeuren van gebruikers van de berichtenbox voor uw organisatie sinds die datum/tijd worden verstuurd. Figuur 6: De abonnementservice kent 3 varianten Welke variant voor uw organisatie van toepassing is bepaalt u tijdens de impactanalyse / voorbereiding op aansluiten. In veel situaties volstaat de eerste variant. De tweede variant is met name bedoeld voor berichtleveranciers die een (zeer) grote populatie van burgers kent (landelijke dekking). De derde variant stuurt alleen mutaties sinds een bepaalde datum. Deze variant kan alleen in combinatie met de tweede variant gebruikt worden. Initieel moet de tweede variant aangeroepen worden om de volledige set met geabonneerden op te vragen. Daarna worden telkens mutaties opgevraagd. Zodra er onverhoopt een sprake van een synchronisatieconflict is, moet de hele set met geabonneerden wederom opgevraagd worden door middel van variant twee. Pagina 15 van 37

16 4.2.1 Adressering Uitwisselingen van berichten over de ebms-koppelvlakstandaard van Digikoppeling is gebaseerd op services. De ServiceID s vind u in het document Handreiking netwerkconnectiviteit (wordt door Logius verstrekt na ontvangst van het Aanvraagformulier). Bij de ebms-koppelvlakstandaard is een zogenaamd CPA (Collaboration Protocol Agreement) noodzakelijk voor iedere koppeling. Dit CPA wordt aangemaakt via de CPA-creatievoorziening 2 en dient vervolgens ingeladen te worden in beide Digikoppeling-adapters. Hetzelfde CPA dat gebruikt wordt voor de berichtaanlevering (paragraaf 5) wordt gebruikt om de Abonnementservice te bevragen Operaties De Abonnementservice verwerkt één type vraagbericht en kent hiermee één operatie. Deze operatie levert een lijst met BSN s van burgers die berichten van uw organisatie willen ontvangen in hun Berichtenbox Vraagbericht Voor de abonnementservice bestaat één vraagbericht voor alle drie de varianten (zie inleiding 4.2). Dit vraagbericht bevat altijd het OIN/HRN van de aanvrager en indien er gebruik gemaakt wordt van variant één wordt het vraagbericht aangevuld met de te valideren BSN s. Indien gebruik gemaakt wordt van variant 3 mutaties moet de mutatiedatum/tijd vanaf opgegeven worden om de mutaties van geabonneerden vast te stellen n.a.v. vorige aanvraag bijgewerkt zijn. De benodigde technische bestanden (XSD-bestanden) voor de Abonnementservice worden door Logius verstrekt na ontvangst van het Aanvraagformulier ontvangt u wanneer u het Aanvraagformulier MijnOverheid (preproductie) naar het Servicecentrum Logius stuurt. Figuur 7: Structuur vraagbericht Abonnementservice Toelichting op elementen vraagbericht Element BerichtLeverancierCode Toelichting Het OIN van uw organisatie, 20 cijfers. 2 Pagina 16 van 37

17 VerzoekId (optioneel) Mutatiedatum BSNLijst BSN Een referentie ID om het vraag en antwoord bericht aan elkaar te relateren. Mutatiedatum en tijd vanaf wanneer de mutaties op geabonneerden toegestuurd moeten worden. Dit is de waarde van DatumTijdVerwerking uit laatst ontvangen antwoordbericht, zie paragraaf Lijst van BSN waarvoor validatie moet plaatsvinden. (Deze lijst is niet van toepassing bij variant 1). Te valideren BSN Voorbeeld vraagbericht De ebms-envelop is voor de overzichtelijkheid achterwege gelaten. Variant 1: <ns0:abonnementaanvraag xmlns:ns0=" AbonnementServiceProcessor/2014/02"> <BerichtLeverancier> <OIN> </OIN> </BerichtLeverancier> <VerzoekId> </VerzoekId> <BSNLijst> <BSN> </BSN> <BSN> </BSN> <BSN> </BSN> <BSN> </BSN> </BSNLijst> </ns0:abonnementaanvraag> Variant 2: <ns0:abonnementaanvraag xmlns:ns0=" /AbonnementServiceProcessor/2014/02"> <BerichtLeverancier> <OIN> </OIN> </BerichtLeverancier> <VerzoekId> </VerzoekId> </ns0:abonnementaanvraag> Variant 3: <ns0:abonnementaanvraag xmlns:ns0=" /AbonnementServiceProcessor/2014/02"> <BerichtLeverancier> <OIN> </OIN> </BerichtLeverancier> <VerzoekId> </VerzoekId> <MutatieDatum> T12:23:16.326Z</MutatieDatum> </ns0:abonnementaanvraag> Antwoordbericht Na het verwerken van het vraagbericht wordt het antwoordbericht verstuurd (asynchroon, conform Digikoppeling-ebMS) met de volgende structuur: Pagina 17 van 37

18 Figuur 8: Structuur antwoordbericht Abonnementservice Toelichting op elementen antwoordbericht Element BerichtLeverancierCode DatumTijdVerwerking VerwerkingsCode VerzoekIdAanvraag Actief Inactief BSNLijst BSN Toelichting Het OIN van uw organisatie, overgenomen vanuit het vraagbericht, 20 cijfers. De systeemdatum en tijd van moment van aanmaken van het antwoordbericht, in DateTime formaat. Bij variant 3 (mutaties) wordt deze waarde gebuikt als Mutatiedatum in het vraagbericht (zie 4.2.4) Status van de verwerking. Standaardwaarde "Verwerkt"; anders staat hier een foutcode. De volgende codes zijn van toepassing: "Verwerkt", "TechnischProbleem", "LeverancierNietBekend", "VerplichteLeverancierNietOndersteund", "BSNLijstOntbreektInAanvraag " "XmlValidatieTegenXsdValtNegatiefUit" VerzoekId dat is meegegeven in het vraagbericht als referentie tussen vraag en antwoord bericht. In geval van succesvolle verwerking bevat dit element de lijst met burgers die geabonneerd zijn op uw organisatie. In geval van succesvolle verwerking bevat dit element de lijst met burgers die het abonnement op uw organisatie beëindigd hebben. (Uitsluitend van toepassing op variant 3) Lijst van BSN waarvoor validatie heeft plaatsgevonden. (Deze lijst is niet van toepassing bij variant 1). Het BSN van de burger Voorbeeld antwoordbericht De ebms-envelop is voor de overzichtelijkheid achterwege gelaten. <ns0:abonnementantwoord xmlns:ns0=" <BerichtInformatie> Pagina 18 van 37

19 <BerichtLeverancier> <OIN> </OIN> </BerichtLeverancier> <DatumTijdVerwerking> T13:20:00.000Z</DatumTijdVerwerking> <VerwerkingsCode>Verwerkt</VerwerkingsCode> <VerzoekIdAanvraag> </VerzoekIdAanvraag> </BerichtInformatie> <Actief> <BSNLijst> <BSN> </BSN> <BSN> </BSN> <BSN> </BSN> <BSN> </BSN> </BSNLijst> </Actief> </ns0:abonnementantwoord> Foutafhandeling Indien er een fout is opgetreden in de verwerking van het vraagbericht, wordt alleen de verwerkingscode teruggegeven. <?xml version="1.0" encoding="utf-8"?> <AbonnementAntwoord xmlns:xsi=" xmlns:xsd=" xmlns=" <BerichtInformatie> <BerichtLeverancier> <OIN> </OIN> </BerichtLeverancier> <DatumTijdVerwerking> T16:34:58+02:00</DatumTijdVerwerking> <VerwerkingsCode>LeverancierNietBekend</VerwerkingsCode> <VerzoekIdAanvraag> </VerzoekIdAanvraag> </BerichtInformatie> </AbonnementAntwoord> Pagina 19 van 37

20 5 Aanleveren Berichtenbox-berichten 5.1 Berichten Verwerkservice Na het Opvragen van geabonneerden (paragraaf 4) wordt via de Berichten Verwerkservice het bericht verstuurd naar de MijnOverheid Berichtenbox van de burger. Deze service maakt gebruik van het asynchrone ebms protocol. Uitgangspunten Berichten Verwerkservice De berichten dienen te voldoen aan de berichtspecificaties zoals in deze paragraaf beschreven. De ontvangen berichten worden op technische juistheid gecontroleerd voordat ze in de Berichtenbox van de burger worden geplaatst; de verantwoordelijkheid voor het technisch juist aanleveren van berichten ligt bij de aangesloten organisatie. Verschillende soorten berichten worden geclassificeerd als berichttypen. De berichttypen dienen vooraf bekend te zijn gemaakt. Hiervoor verkrijgt de organisatie toegang tot het Berichtenbox Leveranciersportaal. Een bericht kan maximaal twee gepersonaliseerde bijlagen bevatten. Per berichttype kunnen maximaal drie standaardbijlagen (bijvoorbeeld een standaard toelichting, brochures of bezwaarmakingsproces) worden voor gedefinieerd. Deze worden vooraf geüpload via het Berichtenbox Leveranciersportaal. De standaardbijlagen worden bij de persoonlijke berichtaanlevering achterwege gelaten. Berichten dienen per batch te worden aangeleverd. Aanlevering van de batch dient aansluitend op het aanmaken van de batch plaats te vinden. Een batch kan uit één of meerdere berichten bestaan. Een batch kan meerdere berichttypen bevatten. Het maximaal aantal dagen tussen de aanmaakdatum van de batch en de datum waarop de actieve berichtenboxen zijn vastgesteld (via Opvragen geabonneerden) bedraagt 7 dagen. Berichten kunnen worden aangeleverd met een publicatiedatum/tijd in de toekomst. Deze publicatiedatum/tijd ligt maximaal 13 dagen in de toekomst, ten opzichte van de aanmaakdatum van de batch Indien geen publicatiedatum/tijd is opgegeven, dan wordt het bericht direct na ontvangst en verwerking door MijnOverheid aan de burger beschikbaar gesteld. Indien ten tijde van de berichtverwerking de publicatiedatum/tijd verstreken is, wordt het bericht direct gepubliceerd. Een berichttekst mag URL s bevatten. Elke URL dient te beginnen met of en moet worden voorafgegaan en gevolgd door ten minste één spatie, bijvoorbeeld: Bij het tonen van het bericht aan de gebruiker wordt de URL als hyperlink gepresenteerd; Uitgangspunten Berichtenbox-bericht: UTF-8: de Berichtenbox gaat uit van de UTF-8 karakterset. Uw organisatie dient gegevens aan de Berichtenbox aan te bieden op basis van deze karakterset3. Berichten die niet aan de karakterset voldoen worden afgekeurd. 3 Webrichtlijnen, voor meer informatie, zie: Pagina 20 van 37

21 Regeleinde: een regeleinde (of lege regel) in de berichttekst moet worden gecodeerd als "\r\n" (zonder de aanhalingstekens). Voorbeeld van een regeleinde en een lege regel: "Geachte heer/mevrouw,\r\n\r\n Hierbij ontvangt u..." PDF-formaat: Een Berichtenbox-bericht kan een of meerdere PDFbijlagen bevatten. Om de toegankelijkheid nu en in de toekomst te waarborgen moeten de PDF-bijlagen van uw organisatie voldoen aan de volgende eisen: 1. Het formaat is conform de open standaard PDF/A waarvan de volgende conformiteitsniveaus zijn toegestaan: PDF/A-1a (ISO ) of PDF/A-2-a (ISO ). 2. De inhoud is conform Web Content Accessibility Guidelines 2.0 (ISO 40500). In uitzonderlijke gevallen mag uw organisatie bijlagen met afwijkend PDF formaat of inhoud aanleveren. Uw organisatie dient de reden hiervoor te verantwoorden en op voorhand te melden bij MijnOverheid, die met het afwijkende formaat moet instemmen. PDF-grootte: de maximale (gezamenlijke) grootte van de gepersonaliseerde bijlage(n) in een individueel bericht is 250 kb ( bytes); Een bericht kan maximaal twee gepersonaliseerde bijlagen bevatten. De 250 kb is gebaseerd op de grootte van de PDFbestanden tezamen. Echter, het Berichtenbox-bericht is feitelijk ongeveer 37% groter dan 250 kb i.v.m. de overhead bij base64- encoding. Daarnaast kan via het Berichtenbox Leveranciersportaal per berichttype maximaal 3 standaardbijlagen worden toegevoegd met een gezamenlijke maximale grootte van 2 MB. Batch-grootte: Een batch bevat maximaal 1000 Berichtenboxberichten. De maximale grootte van een batch is 100 MB (inclusief base64 overhead). Dit betekent dat er met batches van minder dan 1000 berichten gewerkt moet worden indien de som van de grootte van de individuele bijlagen, inclusief base64 overhead, de 100 MB overschrijdt. Figuur 9: Overzicht kenmerken Berichtenbox-berichten Transport: Digikoppeling: ebms-berichten worden met dubbelzijdig TLS (1.0) uitgewisseld met behulp van een PKIoverheid-certificaat. Voor ebms wordt een CPA contract opgesteld waarin het cliënt en server certificaat van Service Requester (uw organisatie) en Service Provider (Berichtenbox MijnOverheid) is opgenomen. Authenticatie: Digikoppeling verplicht het gebruik van PKIoverheid-certificaten inclusief Overheidsidentificatienummer (OIN). Het OIN uit het bericht wordt vergeleken met het OIN uit het CPA. Pagina 21 van 37

22 5.1.1 Adressering Hetzelfde CPA dat gebruikt wordt voor de Abonnementservice (paragraaf 4.2) wordt gebruikt om de Bericht Verwerkservice te benaderen. Het CPA zorgt onder andere voor de adressering. Uw organisatie stuurt via uw Digikoppeling-adapter het bericht naar het adres in die definitie. De ServiceID s vind u in het document Handreiking netwerkconnectiviteit (wordt door Logius verstrekt na ontvangst van het Aanvraagformulier). De CPA moet worden aangemaakt via de CPA-creatievoorziening (zie ook paragraaf 4.2.1) Berichtenbox-bericht Hieronder wordt de structuur van het Berichtenbox-bericht beschreven. De benodigde technische bestanden (XSD-bestanden) voor de Berichtenbox worden door Logius verstrekt na ontvangst van het Aanvraagformulier. Tevens ontvangt u bij de aanvraag de Handreiking netwerkconnectiviteit. Figuur 10: Structuur Berichtenbox-batch Pagina 22 van 37

23 5.1.3 Toelichting op elementen Berichtenbox-batch Element BatchID AanmaakDatum BerichtLeverancierID BerichtID BerichtType PublicatieDatum (optioneel) Onderwerp Berichttekst Referentie (optioneel) GebruikerID SoortGebruiker Inhoud (optioneel) BijlageType (optioneel) Omschrijving (optioneel) Volgorde Toelichting GUID zonder accolades in registry format (bijv. 9F9126B2- C661-4c0f-9E05-7B038906CCCF). Het batchid moet worden herhaald in ieder individueel bericht, hierdoor is het mogelijk om in de toekomst parallel berichten te verwerken deze resultaten op het einde te aggregeren. Hierdoor kan de doorlooptijd van de verwerking worden verkort. Dit ID moet uniek zijn voor elke batch die uw organisatie verstuurt. Datum waarop de batch is aangemaakt. Door organisatie in te vullen (YYYY-MM-DDTHH:MM:SSZ) (bijv T09:30:47Z). De aanmaakdatum mag niet verder dan 13 dagen in het verleden liggen op het moment van aanbieden. OIN (Overheidsidentificatienummer) van uw organisatie. GUID in registry format (bijv. 9F9126C2-C661-4c0f-9E05-7B038906CCCF). Dit ID moet uniek zijn voor ieder bericht dat uw organisatie verstuurt. Soort bericht (brief), aan te maken via het Berichtenbox Leveranciersportaal. Het berichttype moet bestaan. Datum en tijd waarop het bericht wordt gepubliceerd. (YYYY-MM-DDTHH:MM:SSZ) (bijv T09:30:47Z), d.w.z. zichtbaar wordt voor de geadresseerde. De publicatiedatum mag maximaal 13 dagen ná de aanmaakdatum liggen. Indien op het moment van verwerken van het bericht de publicatiedatum inmiddels verstreken is, wordt het bericht direct gepubliceerd. Onderwerp van het bericht. Maximale lengte: 50 tekens. Tekst van het bericht, maximale lengte: 4000 tekens. Een regeleinde is \r\n. Referentiegegevens, maximale lengte: 25 tekens. BSN van de geadresseerde Vaste waarde: Burger De inhoud van de (PDF) bijlage als Base64-encoded-string Vaste waarde: Pdf (Bijlage in PDF of ander toegestaan formaat) (Korte) omschrijving van de bijlage. Maximale lengte: 40 tekens. Als een bericht meerdere bijlagen bevat, kan hiermee de volgorde worden bepaald waarin de bijlagen in de berichtenbox worden getoond. Bij één bijlage komt hier 1 te staan Voorbeeldbericht Berichtenbox-batch De ebms-envelop is voor de overzichtelijkheid achterwege gelaten. <p:berichten xmlns:p=" <p:batchinformatie> <p:batchid>dcf2d436-a655-11e1-942d-63f b</p:batchid> <p:aanmaakdatum> t07:04:30</p:aanmaakdatum> <p:berichtleverancierid> </p:berichtleverancierid> </p:batchinformatie> <p1:bericht xmlns:p1=" <p1:berichtinformatie> <p1:batchid>dcf2d436-a655-11e1-942d-63f b</p1:batchid> Pagina 23 van 37

24 <p1:berichtid>0cf2d436-a655-11e1-942d-63f d</p1:berichtid> <p1:berichttype>bericht1</p1:berichttype> <p1:publicatiedatum> t07:05:30</p1:publicatiedatum> <p1:onderwerp>bericht Onderwerp</p1:Onderwerp> <p1:berichttekst>geachte heer/mevrouw, \r\n Hierbij sturen we u het volgende bericht. \r\n Met vriendelijke groet, \r\n Organisatienaam \r\n <p1:referentie>xyz </p1:referentie> <p1:gebruikerid> </p1:gebruikerid> <p1:soortgebruiker>burger</p1:soortgebruiker> </p1:berichtinformatie> <p1:bijlagen> <p1:bijlage> <p1:inhoud>foautajjjxbxmmc+3zzxl3unsxz5l8wwcqydvr0tbaiwadcb0gydvr0gbihkmihh MIHEBgpghBABh2sBAgIGMIG1MDMGCCsGAQUFBwIBFidodHRwOi8vd3d3LmRpZ2lu b3rhci5ubc9jchmvcgtpb3zlcmhlawqwfgyikwybbquhagiwchpwq29uma==</p1:inhoud> <p1:bijlagetype>pdf</p1:bijlagetype> <p1:omschrijving>apk-herinneringsbrief</p1:omschrijving> <p1:volgorde>1</p1:volgorde> </p1:bijlage> </p1:bijlagen> </p1:bericht> </p:berichten> Mapping van Berichtenbox-elementen op webweergave De onderstaande tabel beschrijft of, en op welke wijze, elementen uit het Berichtenbox-bericht weergegeven worden in de Berichtenbox van de burger. Element BatchID AanmaakDatum BerichtLeverancierID BerichtID BerichtType PublicatieDatum Onderwerp Berichttekst Referentie (optioneel) GebruikerID SoortGebruiker Inhoud (optioneel) BijlageType (optioneel) Omschrijving (optioneel) Volgorde Toelichting Wordt niet getoond in de Berichtenbox van de burger. Wordt niet getoond in de Berichtenbox van de burger. Op basis van het OIN (Overheidsidentificatienummer) wordt de afzender bepaald. De afzendernaam wordt door Logius beheerd. Wordt niet getoond in de Berichtenbox van de burger. Wordt niet getoond in de Berichtenbox van de burger. Tijdstip van verwerken van het bericht of de PublicatieDatum indien deze is ingevuld. Onderwerp van het bericht. Tekst van het bericht. Berichtreferentie. Wordt niet getoond in de Berichtenbox van de burger. Wordt niet getoond in de Berichtenbox van de burger. De PDF-bijlage bij het bericht. Wordt niet getoond in de Berichtenbox van de burger. De naam van de link naar de PDF-bijlage. Wordt niet getoond in de Berichtenbox van de burger, het bepaalt de volgorde indien er meerdere persoonlijke bijlagen meegestuurd zijn. Pagina 24 van 37

25 Figuur 11: Mapping elementen op webweergave (Berichtenoverzicht) Figuur 12: Mapping elementen op webweergave (Berichtenbox-bericht) Retourbericht Na aanlevering en verwerking van een batchbericht vanuit uw organisatie wordt een retourbericht teruggestuurd, hierin staat informatie over het verwerkingsresultaat. Logius raadt sterk aan het verwerkingsresultaat te registreren. Resultaten van het verwerken van batches zijn ook terug te vinden in het Berichtenbox Leverancierportaal. Hieronder wordt de structuur van het retourbericht beschreven. Pagina 25 van 37

26 Pagina 26 van 37

27 Figuur 13: Structuur Retourbericht Naast tellingen van het aantal verwerkte en niet verwerkte berichten wordt voor elk individueel bericht het verwerkingsresultaat teruggemeld Toelichting op elementen Retourbericht Element BerichtLeverancierCode BatchID TotaalAantalOntvangen Berichten AantalBerichtenSuccesvol Verwerkt AantalBerichtenGeen ActieveBoxOfGeabonneert OpLeverancier AantalBerichtenMet TechnischProbleem AantalBerichtenBericht TypeNietCorrect AantalBerichtenPublicatie DatumNietCorrect AantalBerichtenAanmaak DatumNietCorrect Toelichting Het OIN uit de ontvangen batch. Het BatchID van de ontvangen batch. Het totaal aantal berichten dat is ontvangen door de Berichtenbox in de batch met bovenstaand ID. Het aantal berichten dat succesvol is verwerkt door de Berichtenbox vanuit de batch met bovenstaand ID. Het aantal berichten vanuit de batch met bovenstaand ID: waarvoor geen actieve Berichtenbox is gevonden; dat niet afgeleverd kon worden, omdat de burger heeft aangegeven geen berichten van uw organisatie wenst te ontvangen. Het aantal berichten vanuit de batch met bovenstaand ID waarbij een technisch probleem is opgetreden. Het aantal berichten vanuit de batch met bovenstaand ID met een incorrect BerichtType. Het aantal berichten vanuit de batch met bovenstaand ID met een ongeldige PublicatieDatum. Het aantal berichten vanuit de batch met bovenstaand ID met een ongeldige AanmaakDatum. Pagina 27 van 37

28 DatumOntvangen DatumVerwerkt BerichtID BerichtType Verwerkingscode Stadium Ontvangstdatum van de batch met bovenstaand ID. Verwerkingsdatum van de batch met bovenstaand ID. ID (GUID) van het bericht zoals ontvangen in de batch met bovenstaand ID. Soort brief. Resultaat van de verwerking. De volgende waarden kunnen voorkomen: Verwerkt TechnischProbleem NietActiefOfGeabonneerd BerichtTypeNietOndersteund AanmaakDatumLigtTeVerInHetVerleden PublicatieDatumLigtTeVerInDeToekomst BerichtBestaatAl BijlageTeGroot OinInCPAKomtNietOvereenMetOinInBericht XmlValidatieTegenXsdValtNegatiefUit * Geeft aan tijdens welke verwerkingsfase het probleem is geconstateerd. De volgende waarden kunnen voorkomen: ValidateBerichtType ValidateGebruiker StoreMessage NA (Not Applicable) * Bij het retourbericht met de foutcode XmlValidatieTegenXsdValtNegatiefUit vervalt de verwijzing naar het aangeleverde BatchID en BerichtID, overige velden worden met 0 gevuld Voorbeeldbericht Retourbericht De ebms-envelop is voor de overzichtelijkheid achterwege gelaten. <p:berichtverwerkresponse xmlns:p=" <BatchInformatie> <BerichtLeverancierCode> </BerichtLeverancierCode> <BatchID>DCF2D436-A655-11E1-942D-63F B</BatchID> <TotaalAantalOntvangenBerichten>1</TotaalAantalOntvangenBerichten> <AantalBerichtenSuccesvolVerwerkt>1</AantalBerichtenSuccesvolVerwerkt> <AantalBerichtenGeenActieveBoxOfGeabonneertOpLeverancier>0</AantalBerichtenGeenActieveBoxOfGeabonneertOpLeverancier> <AantalBerichtenMetTechnischProbleem>0</AantalBerichtenMetTechnischProbleem> <AantalBerichtenBerichtTypeNietCorrect>0</AantalBerichtenBerichtTypeNietCorrect> <AantalBerichtenPublicatieDatumNietCorrect>0</AantalBerichtenPublicatieDatumNietCorrect> <AantalBerichtenAanmaakDatumNietCorrect>0</AantalBerichtenAanmaakDatumNietCorrect> <DatumOntvangen> T08:04:30</DatumOntvangen> <DatumVerwerkt> T08:04:30</DatumVerwerkt> </BatchInformatie> <Berichten> <p1:bericht xmlns:p1=" <BerichtID>014FA950-A654-11E1-B1E1-0EEF B</BerichtID> <BerichtType>BERICHT1</BerichtType> <VerwerkingsCode>Verwerkt</VerwerkingsCode> <Stadium>NA</Stadium> </p1:bericht> </Berichten> </p:berichtverwerkresponse> Pagina 28 van 37

29 5.1.9 Toelichting Stadium- en Verwerkingscodes Verwerkingscode Verwerkt TechnischProbleem NietActiefOfGeabonneerd BerichtTypeNietOndersteund AanmaakDatumLigtTeVerInHetVerleden PublicatieDatumLigtTeVerInDeToekomst BerichtBestaatAl BijlageTeGroot OinInCPAKomtNietOvereenMetOinInBericht XmlValidatieTegenXsdValtNegatiefUit Stadium ValidatieBerichtType ValidatieGebruiker StoreMessage NA Toelichting Het bericht is verwerkt en opgeslagen in de Berichtenbox van de burger. Er is tijdens het verwerken van het bericht een technisch probleem ontstaan. In het element Stadium is te zien tijdens welke verwerkingsfase het probleem is geconstateerd, zie ook hieronder. De burger voor wie het bericht bestemd is, heeft geen actieve Berichtenbox, bestaat niet of heeft geen abonnement op de berichtleverancier (uw organisatie). Het gebruikte BerichtType bestaat niet of is niet actief. Als uw organisatie de batch aanmaakt wordt een AanmaakDatum gevuld met een datum. Bij aanlevering wordt gecontroleerd of de AanmaakDatum niet verder dan 13 dagen in het verleden ligt ten opzichte van de datum waarop de batch wordt verwerkt. Als een bericht niet direct mag worden getoond aan de burger dan kan uw organisatie er voor kiezen om een publicatiedatum mee te geven. Deze mag echter maximaal 13 dagen na de aanmaakdatum liggen. Een bericht met hetzelfde BerichtID is reeds aangeboden door uw organisatie. De omvang van de persoonlijke bijlage(n) in het aangeboden bericht is te groot. U kunt alleen het OIN gebruiken dat overeenkomt met het OIN uit het CPA en het PKIoverheid-certificaat. Het aangeboden bericht valideert niet tegen het XML-schema (XSD) van het Berichtenbox-bericht. Toelichting In dit stadium is het niet gelukt om het BerichtType te valideren. In dit stadium is het niet gelukt om het burger te valideren. In dit stadium is het niet gelukt om het bericht op te slaan. Dit betekent dat alle stadia succesvol zijn doorlopen. Pagina 29 van 37

30 Foutafhandeling Indien uw organisatie aan de hand van het retourbericht constateert dat berichten niet zijn verwerkt, kunt u aan de hand van de verwerkingscode en stadium bepalen welk probleem zich heeft voorgedaan. Indien het probleem bij uw organisatie ligt kunt u, na oplossen van het probleem, de berichten opnieuw aanbieden in een nieuwe batch. Anders kunt u contact opnemen met Logius Verwerking van batch Zodra de Berichtenbox een berichtenbatch ontvangt van uw organisatie wordt een aantal controles uitgevoerd, voordat het bericht daadwerkelijk in de Berichtenbox van de burger wordt geplaatst. Een bericht wordt pas vrijgegeven indien aan onderstaande condities is voldaan. Terugkoppeling over het verwerkingsresultaat wordt geplaatst op het Berichtenbox Leveranciersportaal en komt terug via de Digikoppeling-adapter, zoals hierboven beschreven, middels het Retourbericht. Op het moment dat de afzender is geauthenticeerd en geautoriseerd start het proces van de controle op de berichten. Van ieder ontvangen bericht wordt gecontroleerd of: Het bericht inclusief gepersonaliseerde bijlage(n) niet groter is dan 250 kb. Het BSN een actieve berichtenbox heeft. Het BSN een abonnement heeft op uw organisatie. Het aangeleverde bericht een geldig en bestaand berichttype is. Berichttypes worden via het Berichtenbox Leveranciersportaal aangemaakt. De aanmaakdatum van het bericht niet meer dan 13 dagen in het verleden ligt. Een eventuele publicatiedatum van het bericht niet meer dan 13 dagen na de aanmaakdatum ligt. Het bericht maximaal 2 gepersonaliseerde bijlagen bevat. Het bericht gebruik maakt van de karakterset UTF-8. Als ten minste één controle negatief uitvalt, wordt een status gemeld op het Berichtenbox Leveranciersportaal en stopt de verwerking van het bericht. Wanneer alle controles zijn uitgevoerd en niet negatief uitvallen wordt het bericht in de Berichtenbox van de burger geplaatst. Berichten die niet aan bovenstaande voorwaarden voldoen worden niet verwerkt. Pagina 30 van 37

31 6 Richtlijnen voor PDF bijlagen Een Berichtenbox-bericht kan een of meerdere PDF-bijlagen bevatten. Documenten moeten leesbaar zijn ongeacht het besturingssysteem of de software die gebruikt wordt. Ook in de toekomst moeten documenten leesbaar zijn met de software die dan gangbaar is. Mensen met een visuele of andere handicap moeten documenten van de overheid kunnen lezen met de hulpmiddelen die ze daarvoor hebben. Dit stelt eisen aan de documenten die de overheid via de berichtenbox verstuurt. Om de toegankelijkheid nu en in de toekomst te waarborgen moeten de PDF-bijlagen van uw organisatie voldoen aan de volgende eisen: 1. Het formaat is conform de open standaard PDF/A waarvan de volgende conformiteitsniveaus zijn toegestaan: PDF/A-1a (ISO ) of PDF/A-2-a (ISO ). 2. De inhoud is conform Web Content Accessibility Guidelines 2.0 (ISO 40500). 3. PDF-grootte: de maximale (gezamenlijke) grootte van de gepersonaliseerde bijlage(n) in een individueel bericht is 250 kb. Daarnaast kunnen per berichttype maximaal 3 standaardbijlagen worden toegevoegd met een gezamenlijke maximale grootte van 2 MB. In de volgende paragrafen worden deze eisen nader toegelicht. 6.1 PDF/A PDF/A staat op de pas toe of leg uit lijst van het Forum Standaardisatie. De instructie rijksdienst inzake aanschaf van ICT-producten en ICTdiensten (besluit WJZ/ van 8/11/2008) verplicht overheden om de open standaarden op de pas toe of leg uit te gebruiken. De Europese Unie stelt dit jaar de standaard EN verplicht, die toegankelijkheidseisen voorschrijft voor ICT producten en diensten. De Europese standaard EN gelast het gebruik van de WCAG 2.0 richtlijnen voor websites en documenten. Alleen PDF/A documenten met het conformiteitsniveau PDF/A-1a (ISO ) of PDF/A-2-a (ISO ) kunnen volledig voldoen aan de WCAG 2.0 richtlijnen voor toegankelijkheid. PDF/A documenten met een conformiteitsniveau PDF/A-1b, PDF/A-2b of PDF/A-2u, en andere PDF standaarden hebben niet het geschikte formaat om te voldoen aan WCAG 2.0 richtlijnen voor toegankelijkheid. Er bestaan applicaties waarmee u kan controleren of PDF documenten voldoen aan het PDF/A-1a of PDF/-2a formaat, en aan de WCAG 2.0 toegankelijkheidsrichtlijnen. De volgende tabel geeft referenties voor deze applicaties. Referentie Link PDF/A-1a en PDF/-2a conformiteitscheck WCAG 2.0 toegankelijkheidscheck voor PDF documenten Pagina 31 van 37