Main content

Hieronder kunt u het archief van onze releases bekijken.
Dit betreft de wijzigingen in de Standaarddocumentatie Digikoppeling.

Release 12 mrt 21 - Wijziging Standaarddocumentatie

Overzicht van de wijzigingen

Achtergrond

Vanaf 1-1-2021 is de richtlijn vanuit PKIOverheid om ‘PKIO Private Root’ certificaten te gebruiken voor machine-to-machine verkeer. In deze release is deze wijziging in de Digikoppeling documentatie verwerkt.

Gewijzigde documenten

De volgende documenten zijn gewijzigd:

Digikoppeling actuele versie vorige versie
Digikoppeling Beveiligingsstandaarden en Voorschriften 1.4 1.3
Digikoppeling Gebruik en achtergrond certificaten 1.6.1 1.6
Digikopeling Overzicht Actuele Documentatie en Compliance 1.6 1.5

Wijzigingen per document

Digikoppeling Beveiligingsstandaarden en voorschriften v1.3

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
  3.2.2 p8 Digikoppeling vereist dat de communicatiepartners PKIoverheid public root certificaten of PKIoverheid private root certificaten gebruiken met een OIN om op een vertrouwelijke wijze gegevens uit te wisselen. Digikoppeling vereist dat de communicatiepartners PKIoverheid private root certificaten gebruiken met een OIN om op een vertrouwelijke wijze gegevens uit te wisselen.    
1 3.3.1 p9

PKI005 Het certificaat moet zijn van het type PKIoverheid public root (PKI Staat der Nederlanden Root) of PKIoverheid private root (PKI Staat der Nederlanden Private Root).
Voor Serviceaanbieders geldt dat zij uiterlijk per 1-1-2021 gebruik van private root certificaten moeten ondersteunen

PKI005 Het certificaat moet zijn van het type PKIoverheid private root (PKI Staat der Nederlanden Private Root). (*) (*) Uitzondering is wanneer er in het kader van certificaatbeheer op 1 server reden is om PKIO public root certificaten te gebruiken voor zowel koppeling als voor webserver. Hier dienen dan bi-lateraal afspraken over te worden gemaakt tussen de partijen. (Bij gebruik van PKIO public root certificaten is een specifieke eis en aandachtspunt dat deze vanwege externe regelgeving altijd binnen drie tot vijf dagen vervangen moeten kunnen worden.)

Deze uitzondering is toegestaan tot 01-12-2022 Voor Serviceaanbieders en Servicegebruikers geldt dat zij uiterlijk per 1-1-2021 gebruik moeten maken van private root certificaten.

   
2 3.3.2 p9 3. Certificaten voor productie wijken af van certificaten voor test doordat zij op verschillende ‘roots’ zijn gebaseerd, respectievelijk ‘PKI root Staat der Nederlanden Root’ (of Staat der Nederlanden Private Root) en ‘PKI TRIAL root’. 3. Certificaten voor productie wijken af van certificaten voor test doordat zij op verschillende ‘roots’ zijn gebaseerd, respectievelijk ‘Staat der Nederlanden Private Root’ en ‘PKI TRIAL root’.

Overzicht van de tekstuele aanpassingen: Aanpassingen Digikoppeling Beveiligingsstandaarden en voorschriften (GitHub)

Digikoppeling Gebruik en achtergrond certificaten v1.6

Document Normatief Release 23-07- 2018 Release 21-08- 2018 Release 16-05- 2019 Release 17-12- 2019 Release 02-09- 2020 Release 12-03- 2021
Wat is Digikoppeling   1.1.1 1.1.1. 1.1.1 1.1.1 1.1.1 1.1.1
DK Beheermodel en releasebeleid   1.5 1.5 1.5 1.5 1.5 1.5
DK Architectuur X 1.5.1 1.5.1 1.51 1.51 1.51 1.51
DK Koppelvlakstandaard WUS X 3.5 3.6 3.7 3.7 3.7 3.7
DK Koppelvlakstandaard EBMS2 X 3.2 3.2 3.3 3.3 3.3 3.3
DK Koppelvlakstandaard Grote Berichten X 3.2   3.2 3.2 3.2 3.2 3.2
# Locatie  Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
  2.1.1 Het Staat der Nederlanden G3 stamcertificaat, de opvolger van het G2 stamcertificaat, is inmiddels geaccepteerd in de certificate stores van alle bekende browsers. Zie de Staatscourant voor details over het G3 stamcertificaat. Het Staat der Nederlanden G3 stamcertificaat, wordt vanaf 1-1-2021 niet langer gebruikt, in plaats daarvan wordt voor machine to machine verkeer (en dus ook voor Digikoppeling) gebruik gemaakt van het Staat der Nederlanden Private Root CA G1 stamcertificaat.    
  2.1.6    - Nieuw: Toelichting private root, zie 2.1.6    

Overzicht releases

DK Identificatie en Authenticatie X 1.4 1.4 1.4 1.4 1.4 1.4
DK Beveiliging standaarden en voorschriften X 1.1 1.1 1.1 1.2 1.3 1.4*
DK Overzicht Actuele Documentatie en Compliance X 1.1 1.2 1.3 1.4 1.5 1.6*
DK Best Practices WUS   1.10 1.10 1.10 1.10 1.10 1.10
DK Best Practices EBMS2   3.1 3.1 3.2 3.2 3.2 3.2
DK Best Practices Grote Berichten    3.1 3.1 3.1 3.1 3.1 3.1
DK Gebruik en achtergrond certificaten   1.5 1.5 1.5 1.5 1.6 1.6.1*

 Met een sterretje* is aangegeven welke onderdelen zijn gewijzigd in de release.  

Release 10 jan 21 - Wijziging Standaarddocumentatie

Overzicht van de wijzigingen

Achtergrond

Het TO Digikoppeling heeft goedkeuring verleend om wijzigingen door te voeren in de Digikoppeling Koppelvlakstandaard WUS en de Voorwaarden Digikoppeling en de Gebruiksvoorwaarden Digikoppeling.

Gewijzigde documenten

De volgende documenten zijn gewijzigd:

Digikoppeling  actuele versie vorige versie
Digikoppeling Koppelvlakstandaard WUS 3.8 3.7
Voorwaarden Digikoppeling 1 januari 2021 1 januari 2021 1 juli 2017
Gebruiksvoorwaarden Digikoppeling 1 januari 2021 1 januari 2021 1 juli 2017
Digikoppeling Overzicht Actuele Documentatie en Compliance 1.6 1.5

Wijzigingen per document

Digikoppeling Koppelvlakstandaard WUS_v3.8

# Locatie  Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
  2.4.2 p12 wsa:To Mandatory Y wsa:To Mandatory N 2020-2 (response header)
1 2.4.3 p12 WM001 Toepassen MTOM wordt door webservice requester bepaald. Aan de webservice kan aangegeven worden of deze MTOM berichten kan ontvangen en versturen. Gezien het gebruik van MTOM door de webservice requester bepaald wordt, moeten alle Digikoppeling WUS implementaties dit ondersteunen. Concreet betekent dit dat in de toolkit wordt aangegeven dat een webservice een response volgens MTOM verstuurt indien deze een MTOM request heeft ontvangen en een niet geoptimaliseerd bericht verstuurt indien het request ook niet geoptimaliseerd was. De webservice requester neemt dus het initiatief hierin. WM001 Toepassen MTOM wordt door webservice provider bepaald. Bij het inrichten bepaalt de provider of een koppelvlak wel of geen ondersteuning biedt voor MTOM. Bij een nieuwe koppeling in samenspraak, bij toevoegen van een afnemer aan een bestaande dienst dient deze zich te conformeren aan de bestaande inrichting (en wel of niet gebruik van MTOM).     2020-3  

Voorwaarden Digikoppeling en Gebruiksvoorwaarden Digikoppeling

Belangrijkste wijzigingen

De volgende grote wijzigingen zijn doorgevoerd in beide voorwaarden documenten:

  • Private partijen met een publieke taak kunnen SubOIN’s aanvragen
  • Private partijen kunnen ten behoeve van (SAAS-)dienstverlening aan hun publieke klanten SubOIN’s aanvragen

Verdere wijzigingen

Ook een aantal andere onderdelen van de voorwaarden zijn gewijzigd in het kader van onderhoud en aanpassingen in de Digikoppeling dienstverlening:

  • Geen vermelding meer t.b.v. e-factureren in de COR (Centrale OIN Raadpleegvoorziening)
  • Vermelding van organisatiecodes in de COR
  • Reikwijdte van de Digikoppeling Compliancevoorziening,
  • Functioneren conform de Digikoppelingstandaarden
  • Voorwaarden DK en Gebruiksvoorwaarden Digikoppeling in lijn gebracht
  • Tekstueel her en der een en ander verbeterd of consistent gemaakt.

De gedetailleerde wijzigingen per document kunt hier nalezen:

  • Voorwaarden Digikoppeling
  • Gebruiksvoorwaarden Digikoppeling

Overzicht releases

Document Normatief Release 21-08- 2018 Release 16-05- 2019 Release 17-12- 2019 Release 02-09- 2020 Release 10-01- 2021
Wat is Digikoppeling   1.1.1. 1.1.1 1.1.1 1.1.1 1.1.1
DK Beheermodel en releasebeleid   1.5 1.5 1.5 1.5 1.5
DK Architectuur X 1.5.1 1.51 1.51 1.51 1.51
DK Koppelvlakstandaard WUS X 3.6 3.7 3.7 3.7 3.8*
DK Koppelvlakstandaard EBMS2 X 3.2 3.3 3.3 3.3 3.3
DK Koppelvlakstandaard Grote Berichten X 3.2 3.2 3.2 3.2 3.2
DK Identificatie en Authenticatie X 1.4 1.4 1.4 1.4 1.4
DK Beveiliging standaarden en voorschriften X 1.1 1.1 1.2 1.3 1.3
DK Overzicht Actuele Documentatie en Compliance X 1.2 1.3 1.4 1.5 1.6*
DK Best Practices WUS   1.10 1.10 1.10 1.10 1.10
DK Best Practices EBMS2   3.1 3.2 3.2 3.2 3.2
DK Best Practices Grote Berichten    3.1 3.1 3.1 3.1 3.1
DK Gebruik en achtergrond certificaten   1.5 1.5 1.5 1.6 1.6

 Met een sterretje* is aangegeven welke onderdelen zijn gewijzigd in de release.

Release 14 okt 20 - Wijziging Standaarddocumentatie

Aanpassingen

Digikoppeling Grote berichten v3.3 is t.o.v. v3.2 uitgebreid met ondersteuning voor het PUSH principe (d.w.z. het als verzender uploaden van grote bestanden naar de ontvanger). Naar aanleiding van de resultaten van de publieke consultatie van 21-4-2020 is besloten om v3.3 backwards compatible te houden met v3.2 van de standaard voor wat betreft het PULL principe en bijbehorend XSD schema.

Gewijzigde documenten

De volgende documenten zijn gewijzigd:

Digikoppeling actuele versie vorige versie
Digikoppeling_Koppelvlakstandaard_Grote_berichten   3.3 3.2
Digikoppeling Overzicht Actuele Documentatie en Compliance   1.6 1.5

Overzicht wijzigingen DK Grote Berichten v3.3

Algemeen

Referentie Specificatie v3.2 (Oorspronkelijke tekst) Specificatie v3.3  (Nieuwe tekst)
VW000 Partijen MOGEN bilateraal overeen komen bij welke MiB berichtomvang de standaard Grote Berichten van toepassing is of dat volstaan kan worden met Digikoppeling WUS (bevragingen) dan wel Digikoppeling ebMS2 (meldingen) sec (ongewijzigd)
  Een harde grens voor de berichtomvang is lastig te bepalen en in praktische zin is er sprake van overlap. Daarom is er voor gekozen dat partijen bilaterale afspraken kunnen maken waarin afgeweken wordt van de genoemde grens onder VW001, met dien verstande dat door het bilateraal karakter het nooit als argument gebruikt kan worden om andere organisaties te verplichten hieraan te voldoen. (ongewijzigd)
VW001 Als partijen niet tot overeenstemming komen MOETEN zij berichten groter dan 20 MiB via het Koppelvlak Grote Berichten afhandelen. (ongewijzigd)
  Niet elke ontvanger is in staat om grote berichten te ontvangen (en te verwerken). Daarnaast dient te worden voorkomen dat grote berichten het transactionele berichtenverkeer eventueel zouden kunnen verstoren. Daarom dient ten aanzien van de omvang een harde grens te worden afgesproken. (ongewijzigd)
VW002 Voor de overdracht van metadata MOET gebruik gemaakt worden van Digikoppeling, zoals aangeven in het hoofdstuk Metadata in dit document. (ongewijzigd)
VW003 Voor de overdracht van grote bestanden MOET gebruik gemaakt worden van het mechanisme zoals aangeven in het hoofdstuk Bestandsoverdracht in dit document. (ongewijzigd).  

Metadata

Referentie Specificatie v3.2 (Oorspronkelijke tekst) Specificatie v3.3  (Nieuwe tekst)
MD000 Metadata MOET verstuurd worden middels een WUS en/of ebMS bericht. (ongewijzigd)

 

Referentie Specificatie v3.2 (Oorspronkelijke tekst) Specificatie v3.3  (Nieuwe tekst)
MD001 De metadata XML-structuur MOET voldoen aan het XML schema in hoofdstuk Metadata XML Schema Definitie.   De metadata kan een op zichzelf staand bericht zijn, maar ook een deel van een groter bericht. Het is daarbij ook toegestaan om meerdere grote bestanden in een bericht op te nemen; voor ieder afzonderlijk bestand dient dan afzonderlijk metadata in het bericht te worden opgenomen. (ongewijzigd)
MD002 Voor ieder groot bestand MOET een unieke URL gegenereerd te worden; deze URL dient gebruikt te worden om het betreffende bestand op te halen. De URL is dus uniek voor het gehele DigiKoppeling domein en wordt in het meta-bericht via het element <senderUrl> verstrekt aan de ontvanger.   Door aan ieder bestand een unieke URL toe te kennen kan gegarandeerd worden dat het meta-bericht altijd aan het juiste bestand refereert. Het is wel toegestaan om hetzelfde bestand meerdere keren te verzenden (meerdere ontvangers); iedere ontvanger ontvangt dan wel een eigen meta-bericht, maar de URL verwijst dan telkens naar hetzelfde bestand. Ook is het toegestaan om meerdere unieke URL’s naar hetzelfde bestand te laten verwijzen. Voor ieder groot bestand MOET een unieke URL gegenereerd te worden; deze URL dient gebruikt te worden om het betreffende bestand op te halen. De URL is dus uniek voor het gehele Digikoppeling domein en wordt in het meta-bericht via het element <location> verstrekt aan de ontvanger. Bij een pull wordt hier <senderUrl> gevuld en bij push wordt hier <receiverUrl> gevuld.   Door aan ieder bestand een unieke URL toe te kennen kan gegarandeerd worden dat het meta-bericht altijd aan het juiste bestand refereert. Het is wel toegestaan om hetzelfde bestand meerdere keren te verzenden (meerdere ontvangers); iedere ontvanger ontvangt dan wel een eigen meta-bericht, maar de URL verwijst dan telkens naar hetzelfde bestand. Ook is het toegestaan om meerdere unieke URL’s naar hetzelfde bestand te laten verwijzen.
MD003 De metadata MAG het moment aangeven (datum/tijd) waarop het grote bestand beschikbaar zal zijn (element <creationTime>). Het datum/tijd formaat is een UTC tijd in een DateTime W3C formaat [W3C- DateTime] met optionele  ‘Z’ (UTC) aanduiding. ALS dit veld ontbreekt of het moment ligt in het verleden MOET het bestand, uiterlijk op het moment dat de metadata verzonden wordt, beschikbaar zijn. De metadata MAG het moment aangeven (datum/tijd) waarop het grote bestand beschikbaar zal zijn (element <creationTime>) ALS dit veld ontbreekt of het moment ligt in het verleden MOET het bestand, uiterlijk op het moment dat de metadata verzonden wordt, beschikbaar zijn.

 

Referentie Specificatie v3.2 (Oorspronkelijke tekst) Specificatie v3.3  (Nieuwe tekst)
MD004 De metadata MAG het moment aangeven tot wanneer het grote bestand beschikbaar zal zijn.Het grote bestand MOET dan tenminste beschikbaar zijn tot het moment dat in de metadata aangegeven wordt (element <expirationTime>).; na dat moment is de beschikbaarheid van het bestand niet meer gegarandeerd. Het datum/tijd formaat is een DateTime W3C formaat [W3C-DateTime] met de optionele ‘Z’ (UTC) aanduiding.   Door een beperking op te leggen aan de beschikbaarheid wordt voorkomen dat het niet duidelijk is wanneer de betreffende bestanden weer mogen worden verwijderd. De metadata MAG het moment aangeven tot wanneer het grote bestand beschikbaar zal zijn. Het grote bestand MOET dan tenminste beschikbaar zijn tot het moment dat in de metadata aangegeven wordt (element <expirationTime>).; na dat moment is de beschikbaarheid van het bestand niet meer gegarandeerd.   Door een beperking op te leggen aan de beschikbaarheid wordt voorkomen dat het niet duidelijk is wanneer de betreffende bestanden weer mogen worden verwijderd.
MD005 De metadata MOET aangeven hoe groot het bestand is, uitgedrukt in het aantal bytes (element <size>). Door de omvang van een bestand vooraf ter beschikking te stellen kunnen de benodigde resources al vooraf gepland worden. De metadata MOET aangeven hoe groot het bestand is, uitgedrukt in het aantal bytes (element <size>). Indien met deelbestanden wordt gewerkt: de metadata MOET aangeven hoeveel deelbestanden het zijn, hoe groot elk van de deelbestanden is zijn en hoe groot het totale bestand is   Door de omvang van een bestand vooraf ter beschikking te stellen kunnen de benodigde resources al vooraf gepland worden.
MD006 De metadata MOET een checksum geven van het bestand (element <checksum>). Voorlopig dient alleen het MD5 algoritme ondersteund te worden; andere algoritmes kunnen in de toekomst eventueel worden toegevoegd. Deze checksum dient te worden weergegeven als een string van 32 hexadecimale digits (i.e. a t/m f en 0 t/m 9, case-insensitive) [RFC1321]. Door een checksum toe te voegen kan de inhoud van een bestand na de overdracht geverifieerd worden. Voorlopig dient alleen het MD5 algoritme te worden ondersteund; andere algoritmes kunnen in de toekomst eventueel worden toegevoegd. De metadata MOET een checksum geven van het bestand (element <checksum). Indien met deelbestanden wordt gewerkt: de metadata MOET een checksum geven van het totale bestand (element <checksum). Deze checksum dient te worden weergegeven als een string van hexadecimale digits.   Toegestane algoritmen zijn: MD5, SHA-1, SHA256, SHA384, SHA512. Aanbevolen algoritmen zijn: SHA256, SHA384, SHA512. Door een checksum toe te voegen kan de inhoud van een bestand na de overdracht geverifieerd worden. De toepassing van deze algoritmen is hier gericht op (en beperkt tot) detectie van transmissiefouten mbv een checksum. MD5 en SHA-1 zijn daarom in deze context en in verband met backwards compatibiliteit opgenomen als toegestaan.    
Referentie Specificatie v3.2 (Oorspronkelijke tekst) Specificatie v3.3  (Nieuwe tekst)
MD007 De metadata MOET de naam van het bestand opgeven, als string, met een lengte van maximaal 200 karakters (element <filename>). De toegestane karakters zijn letters, cijfers, punt, underscore, en hyphen.  De naam van het bestand moet uniek zijn in de context van de uitwisseling tussen twee partijen (OIN verzender – OIN ontvanger). De eisen ten aanzien van bestandnamen kunnen voor ieder platform verschillend zijn; daarom kan de opgegeven bestandsnaam niet altijd als bestandsnaam aan de zijde van de ontvanger gebruikt worden. (ongewijzigd)
MD008 WUS/ebMS bericht waar het onderdeel vanuit maakt (attribuut <contextId>). Met behulp van de contextID is het mogelijk om de context van de applicatie op te nemen. Ook is het mogelijk een correlatie aan te brengen tussen het bestand en de metadata. Daarvoor moet het bestand dezelfde contextID bevatten. (ongewijzigd)
MD009 De metadata MOET het Internet media type (MIME type of Content-type) specificeren van het bestand  (element <contentType>) [RFC2046]. (ongewijzigd)
MD010 De metadata MOET de URL van de verzender  (element <senderUrl>) of ontvanger (element <receiverUrl>) bevatten. De URL van de ontvanger MOET NIET gebruikt worden. De URL van de ontvanger dient vooralsnog niet gebruikt te worden. Daarom is momenteel alleen het ophalen (http-get) van grote bestanden mogelijk. De metadata MOET bij pull de URL van de verzender  (element <senderUrl> en bij push de URL van de ontvanger (element <receiverUrl>) bevatten.

Bestandsoverdracht functionaliteit

Referentie Type Specificatie v3.2 (Oorspronkelijke tekst) Specificatie v3.3  (Nieuwe tekst)
GB000 PUSH / PULL De bestandsoverdracht MOET gerealiseerd worden op basis van het HTTP protocol, versie 1.1, conform [RFC7230-7235]. (ongewijzigd)

 

Referentie Type Specificatie v3.2 (Oorspronkelijke tekst) Specificatie v3.3  (Nieuwe tekst)
GB001 PULL Zowel de client als de server MOET de BYTE-RANGE optie ondersteunen conform [RFC7233] (i.e. Range, Ifmatch, If-range, ETag en Content-range) [RFC72327233].    De BYTE-RANGE optie wordt gebruikt om in geval van een resume onnodige hertransmissie van data te voorkomen. Hierdoor kan de voortgang van de bestandsoverdracht gegarandeerd worden.  De ondersteuning van de byte ranges is niet verplicht conform de RFC maar in de Digikoppeling-context wel. (ongewijzigd)
GB002 PUSH / PULL De client MOET de bestandsoverdracht initiëren door middel van een HTTP GET request conform [RFC7231]. De client MOET de bestandsoverdracht initiëren door middel van een HTTP GET request (bij PULL) of een HTTP PUT (bij PUSH) conform [RFC7231].
GB003 PULL Indien de client een OK response ontvangt (200), dan kan de client het grote bestand op basis van deze response reconstrueren; eventuele eerder ontvangen bytes MOET de client daarbij negeren (of overschrijven). (ongewijzigd)
GB004 PULL Indien de client een Partial Content response ontvangt (206), dan MOET de client het grote bestand op basis van deze en alle eerdere (partiële) responses reconstrueren; eventuele overlappende byte ranges MOET de client daarbij overschrijven met de laatst ontvangen data. (ongewijzigd)
Referentie Type Specificatie v3.2 (Oorspronkelijke tekst) Specificatie v3.3  (Nieuwe tekst)
GB005 PULL Indien de HTTP verbinding verbroken wordt voordat het volledige grote bestand ontvangen is, en de client wil de overdracht hervatten dan MOET dit plaatsvinden door middel van een “Range” request conform [RFC7233]. De “Range” request maakt deel uit van de BYTE-RANGE optie. Indien de server byte ranges ondersteunt, dan zal deze een Partial Content response (206) naar de client sturen; indien de server geen byte ranges ondersteunt, dan zal deze een OK response sturen. De exacte response van de server is afhankelijke van eventueel aanwezige condities (if-range, if-match en if-unmodifiedsince) [RFC7233]. (ongewijzigd)
GB016 PUSH (nieuw) Bij elke HTTP PUT MOET het bestand aan de ontvangende kant worden overschreven.
GB017 PUSH (nieuw) Verzender KAN ZIP toepassen als container om de payload heen. Ook moet multipart met zip worden ondersteund. Compressie is geen vereiste of doel van ZIP. Wel een mogelijkheid.
GB018 Algem een (nieuw) De verzender MOET foutherstel kunnen uitvoeren nav het response bericht

Beveiliging

Referentie Type Specificatie v3.2 (Oorspronkelijke tekst) Specificatie v3.3  (Nieuwe tekst)
GB006 PUSH / PULL Het HTTP transport MOET beveiligd zijn met TLS. Aanbieder en afnemer ondersteunen de minimaal ondersteunde TLS encryptie algoritmen en sleutellengtes zoals beschreven in het [Digikoppeling Beveiligingsdocument]) op basis van een valide PKIoverheid certificaat [PKICert]. (ongewijzigd)
    Meer informatie in het [Digikoppeling Beveiligingsdocument] (ongewijzigd)
GB007 PUSH / PULL De minimaal ondersteunde TLS encryptie algoritmen en sleutellengtes worden beschreven in het [Digikoppeling Beveiligingsdocument]. (ongewijzigd)
    Meer informatie in het [Digikoppeling Beveiligingsdocument] (ongewijzigd)
GB008 PUSH / PULL Zowel de client als de server organisatie MOET zich authentiseren met een PKIoverheid certificaat [PKICA, PKI-Cert]. (ongewijzigd)
    De basis voor authenticatie en autorisatie in Digikoppeling is OIN. Achtergronden over dit gebruik zijn opgenomen in de Digikoppeling richtlijnen [Digikoppeling-Cert] (2-zijdig TLS). (ongewijzigd)
GB009 PUSH / PULL De server organisatie MOET het transport autoriseren op basis van het OIN van een valide client certificaat [Digikoppeling-Cert]. (ongewijzigd)
GB010 PUSH / PULL Indien de server een HTTP request ontvangt van een niet geautoriseerd OIN (in het client certificaat)  dan MOET een HTTP 403 (Forbidden) response naar de client gestuurd worden (ongewijzigd)
GB011 PUSH / PULL De server moet certificaatrevocatie-lijsten (CRL) gebruiken [PKI-Policy]. (ongewijzigd)
GB012 PUSH / PULL Het HTTPS transport MOET over poort 443 plaatsvinden. (ongewijzigd)
Referentie Type Specificatie v3.2 (Oorspronkelijke tekst) Specificatie v3.3  (Nieuwe tekst)
GB019 PUSH / PULL (nieuw) IP Whitelisting KAN worden toegepast om toegang tot de PUSH server af te schermen
GB020 PUSH / PULL (nieuw) Afschermen van de PUSH server KAN door toepassing van Diginetwerk

Betrouwbaarheid

Referentie Type   Specificatie
GB013 Algem een Voor meldingen, zoals bedoeld in de Digikoppeling architectuur, MOET een retry mechanisme toegepast worden dat rekening houdt met eventuele beperkte beschikbaarheid van het netwerk en/of de server (service-window). De specificatie van het aantal retries en tijdswindow vormt een situationeel af te spreken gegeven. Dit komt overeen met (afspraken over) de configuratie van ebMS2 implementaties. (ongewijzigd)
GB014 Algem een Indien na ontvangst de omvang van het bestand niet overeen komt met de omvang uit het meta-bericht, dan MOET de bestandsoverdracht als niet-succesvol beschouwd worden (size error). (ongewijzigd)
GB015 Algem een Indien na ontvangst de checksum van het bestand niet overeen komt met de checksum uit het meta-bericht, dan MOET de bestandsoverdracht als nietsuccesvol beschouwd worden (checksum error). (ongewijzigd)

Toegevoegd toelichting op pag 12:

Opbouw en structuur XML Schema definities

Om volledig backwards compatible te blijven met de vorige versie van de DK GB standaard waarin alleen het PULL principe was gespecificeerd worden voor PULL en PUSH aparte schema’s gehanteerd waarbij het PULL schema ongewijzigd is t.o.v. de vorige versie.

PULL Schema

Het PULL schema bevat een request bericht definitie. De DK GB PULL variant laat de invulling van de response verder vrij en definieert alleen (size error) en (checksum error) in algemene zin.

PUSH Schema
Het PUSH schema kent een request en een response bericht definitie. De PUSH request biedt de mogelijkheid om eventueel aan te geven in het bericht dat het grote bestand uit meerdere onderdelen (‘parts’) bestaat. Gebruik van de PUSH response definitie is optioneel. Partijen mogen ook overeenkomen om een eigen berichtstructuur voor de response te gebruiken. Indien het responsebericht van het PUSH XML Schema wordt gebruikt moet het volledig worden ingevuld (D.w.z. de ontvangststatus van het grote bestand en van de eventuele onderdelen zowel bij succesvolle ontvangst als bij fouten).

PUSH response bericht statuscodes

De volgende statuscodes zijn voorgedefinieerd in het PUSH responsebericht:

  • OK
  • FILE_NOT_FOUND
  • CHECKSUM_TYPE_NOT_SUPPORTED
  • CHECKSUM_ERROR
  • INCORRECT_FILE_SIZE
  • COMPRESSION_NOT_SUPPORTED
  • DECOMPRESSION_ERROR
  • UNKNOWN_ERROR

Bijlage: XSD Schema struktuur

Pull request

Pull request

Push request

Push Request

Push Response

Push Response

Overzicht Releases

Document Normatief Release 23-07- 2018 Release 21-08- 2018 Release 16-05- 2019 Release 17-12- 2019 Release 02-09- 2020 Release 14-10- 2020
Wat is Digikoppeling   1.1.1 1.1.1. 1.1.1 1.1.1 1.1.1 1.1.1
DK Beheermodel en releasebeleid   1.5 1.5 1.5 1.5 1.5 1.5
DK Architectuur X 1.5.1 1.5.1 1.51 1.51 1.51 1.51
DK Koppelvlakstandaard WUS X 3.5 3.6* 3.7* 3.7 3.7 3.7
DK Koppelvlakstandaard EBMS2 X 3.2 3.2 3.3* 3.3 3.3 3.3
DK Koppelvlakstandaard Grote Berichten X 3.2   3.2 3.2 3.2 3.2 3.3*
DK Identificatie en Authenticatie X 1.4 1.4 1.4 1.4 1.4 1.4
DK Beveiliging standaarden en voorschriften X 1.1 1.1 1.1 1.2* 1.3* 1.3
DK Overzicht Actuele Documentatie en Compliance X 1.1 1.2* 1.3* 1.4* 1.5* 1.6*
DK Best Practices WUS   1.10 1.10 1.10 1.10 1.10 1.10
DK Best Practices EBMS2   3.1 3.1 3.2* 3.2 3.2 3.2
DK Best Practices Grote Berichten    3.1 3.1 3.1 3.1 3.1 3.1
DK Gebruik en achtergrond certificaten   1.5 1.5 1.5 1.5 1.6* 1.6

Met een sterretje* is aangegeven welke onderdelen zijn gewijzigd in de release.

Release 2 sept 20 - Wijziging Standaarddocumentatie

Overzicht van de wijzigingen

Achtergrond

Het TO Digikoppeling heeft goedkeuring verleend om het toestaan van ‘PKIO Private Root’ certificaten expliciet te benoemen in de Digikoppeling voorschriften.

Gewijzigde documenten

De volgende documenten zijn gewijzigd:

Digikoppeling actuele versie vorige versie
Digikoppeling Beveiligingsstandaarden en Voorschriften 1.3 1.2
Digikoppeling Gebruik en achtergrond certificaten 1.6 1.5
Digikopeling Overzicht Actuele Documentatie en Compliance 1.5 1.4

Wijzigingen per document

Digikoppeling Beveiligingsstandaarden en voorschriften v1.2

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
 

3.2.2
p8

Digikoppeling vereist dat de communicatiepartners PKIoverheid certificaten gebruiken met een OIN om op een vertrouwelijke wijze gegevens uit te wisselen. Digikoppeling vereist dat de communicatiepartners PKIoverheid public root certificaten of PKIoverheid private root certificaten gebruiken met een OIN om op een vertrouwelijke wijze gegevens uit te wisselen. 2020-1  
1 3.3.1 P9 (geen) PKI005 Het certificaat moet zijn van het type PKIoverheid public root (PKI Staat der Nederlanden Root) of PKIoverheid private root (PKI Staat der Nederlanden Private Root).    Voor Serviceaanbieders geldt dat zij uiterlijk per 1-1-2021 gebruik van private root certificaten moeten ondersteunen.     2020-1  
2 3.3.2 p9 3. Certificaten voor productie wijken af van certificaten voor test doordat zij op verschillende ‘roots’ zijn gebaseerd, respectievelijk ‘PKI root Staat der Nederlanden’ en ‘PKI TRIAL root’.    3. Certificaten voor productie wijken af van certificaten voor test doordat zij op verschillende ‘roots’ zijn gebaseerd, respectievelijk ‘PKI root Staat der Nederlanden Root’ (of Staat der Nederlanden Private Root) en ‘PKI TRIAL root’.     2020-1  
3 3.3.2 p9 Tabel eisen PKIO <Verwezen wordt naar PvE PKIO> (Om documentbeheer te vereenvoudigen en actualiteit van informatie te garanderen wordt informatie niet overgenomen uit PvE PKIO, maar wordt verwezen)   -

Digikoppeling Gebruik en achtergrond certificaten v1.5

# Locatie  Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
  2.1.6    - Nieuw: Toelichting private root, zie 2.1.6 2020-1  

Overzicht releases

Document Normatief Release 23-07- 2018 Release 21-08-2018 Release 16-05-2019 Release 17-12-2019 Release 02-09- 2020
Wat is Digikoppeling   1.1.1 1.1.1. 1.1.1 1.1.1 1.1.1
DK Beheermodel en releasebeleid   1.5 1.5 1.5 1.5 1.5
DK Architectuur X 1.5.1 1.5.1 1.51 1.51 1.51
DK Koppelvlakstandaard WUS X 3.5 3.6* 3.7* 3.7 3.7
DK Koppelvlakstandaard EBMS2 X 3.2 3.2 3.3* 3.3 3.3
DK Koppelvlakstandaard Grote Berichten X 3.2   3.2 3.2 3.2 3.2
DK Identificatie en Authenticatie X 1.4 1.4 1.4 1.4 1.4
DK Beveiliging standaarden en voorschriften X 1.1 1.1 1.1 1.2* 1.3*
DK Overzicht Actuele Documentatie en Compliance X 1.1 1.2* 1.3* 1.4* 1.5*
DK Best Practices WUS   1.10 1.10 1.10 1.10 1.10
DK Best Practices EBMS2   3.1 3.1 3.2* 3.2 3.2
DK Best Practices Grote Berichten    3.1 3.1 3.1 3.1 3.1
DK Gebruik en achtergrond certificaten   1.5 1.5 1.5 1.5 1.6*

 Met een sterretje* is aangegeven welke onderdelen zijn gewijzigd in de release.

Release 17 dec 19 - Wijziging Standaarddocumentatie

Overzicht van de wijzigingen

Achtergrond

NCSC heeft beveiligingsrichtlijnen voor TLS uitgebracht (ICT Beveiligingsrichtlijnen voor Transport Layer Security (TLS) versie 2.0). In deze release van de Digikoppeling standaard zijn de Digikoppeling beveiligingsstandaarden en voorschriften bijgewerkt conform deze nieuwe NCSC richtlijnen en adviezen. Daarnaast is ook het onderdeel XML encryption in het voorschrift geactualiseerd en voorzien van meer toelichting.

Gewijzigde documenten

De volgende documenten zijn gewijzigd:

Digikoppeling actuele versie vorige versie
Digikoppeling Beveiligingsstandaarden en Voorschriften 1.2 1.1
Digikoppeling Overzicht Actuele Documentatie en Compliance

1.4

1.3

Wijzigingen per document

Digikoppeling Beveiligingsstandaarden en voorschriften v1.2

#

Locatie 

Oorspronkelijke tekst

Gewijzigd in

# RfC

Toelichting

 

4.1

TLS 1.2 (RFC5246)

Verplicht

TLS 1.2 (RFC5246)  Verplicht(*)

TLS 1.3 (RFC8446) Optioneel(*)

NCSC

 

1

4.2 p11

TLS003 

De TLS implementatie mag niet op SSL v3 terug kunnen vallen.  Backward compatibility mode voor SSL3 dient te worden uitgezet.

TLS003

De TLS implementatie mag niet op SSL v3 en eerdere versies terugvallen Backward compatibility mode voor SSL v3 en eerdere versies dient te worden uitgezet.

NCSC

 

2

4.2 p11

TLS004 

TLS 1.0 en TLS 1.1 zijn niet meer toegestaan                 

Niet meer toegestaan vanaf 10-9-2016

TLS004

Een Serviceaanbieder is verplicht TLS versie 1.2 te ondersteunen, daarnaast is het aanbevolen voor een Serviceaanbieder om TLS versie 1.3 te ondersteunen.

Als een Serviceaanbieder TLS versie 1.3 aanbiedt dan is het aanbevolen voor

Serviceafnemers om TLS 1.3 te gebruiken

NCSC geeft aan: “De beste bescherming wordt momenteel geboden door de meest

NCSC

 

      recente TLS versie: TLS 1.3” Zie [NCSC ICT-beveiligingsrichtlijnen voor TLS]   TLS 1.0 en TLS 1.1 zijn niet meer toegestaan   Niet meer toegestaan  binnen de Digikoppeling standaard vanaf 10-9-2016      
3 4.2 p11 TLS005  Voor communicatie over HTTPS wordt port 443 gebruikt. TLS005  Het is verplicht voor communicatie over HTTPS port 443 te gebruiken  Port 443 is standaard poort voor HTTPS verkeer NCSC  
4 4.2 p11  (geen) TLS006    Het is verplicht te voldoen aan de NCSC ICT-beveiligingsrichtlijnen voor TLS         NCSC  
5 5.1.1  p12

TLSCIPH001 - Minimaal verplicht De onderstaande TLS encryptie algoritmen en sleutellengtes MOETEN minimaal worden ondersteund:

  • TLS_RSA_WITH_AES_256_CBC_S HA
  • TLS_RSA_WITH_AES_128_CBC_S HA
TLSCIPH001 De gebruikte TLS cryptografische algoritmen moeten de NCSC classificatie ‘voldoende’ of ‘goed’ hebben.   TLS cryptografische algoritmen met de NCSC classificatie ‘uit te faseren’ dienen zo spoedig mogelijk maar uiterlijk 01-012021 te worden uitgefaseerd.       NCSC  
6 5.1.1

TLSCIPH002- Sterk aanbevolen   Ondersteuning van de volgende aanvullende algoritmen en sleutellengtes wordt sterk aanbevolen om interoperabiliteit en veiligheid in de toekomst zeker te stellen:

  • TLS_RSA_WITH_AES_256_CBC_S HA256
  • TLS_RSA_WITH_AES_128_CBC_S HA256
Vervalt     NCSC  
9 5.3.1  ENC003 (oorspronkelijke tekst vervalt)      
10     ENC004 De ondersteunde data encryption (data versleuteling) algoritmen zijn: [3DES] of [AES128] of  [AES256] [XML Encryption]  

ENC003 De ondersteunde data encryption (data versleuteling) algoritmen zijn: 3DES AES128 AES256

[XML Encryption]

(Gebruik GCM mode indien beschikbaar anders CBC mode in combinatie met een signature)

[AES128-CBC]

[AES128-GCM]

[AES256-CBC]

[AES256-GCM]

XML encryption Nummering Aangepast
11   ENC005 Het Key transport algorithm maakt gebruik van de RSA1_5 of RSA-OAEP algorithmen.   [RSA1_5]  [RSA-OAEP]  [XML Encryption]

ENC004 Het Key transport algorithm maakt gebruik van de RSA-OAEP algoritmen.

[RSA-OAEP]

[XML Encryption]

XML encryption

Overzicht Releases

Document Normatief Release 23-07- 2018 Release 21-08- 2018 Release 16-05- 2019 Release 17-12- 2019
Wat is Digikoppeling   1.1.1 1.1.1. 1.1.1 1.1.1
DK Beheermodel en releasebeleid   1.5 1.5 1.5 1.5
DK Architectuur X 1.5.1 1.5.1 1.51 1.51
DK Koppelvlakstandaard WUS X 3.5 3.6* 3.7* 3.7
DK Koppelvlakstandaard EBMS2 X 3.2 3.2 3.3* 3.3
DK Koppelvlakstandaard Grote Berichten X 3.2   3.2 3.2 3.2
DK Identificatie en Authenticatie X 1.4 1.4 1.4 1.4
DK Beveiliging standaarden en voorschriften X 1.1 1.1 1.1 1.2*
DK Overzicht Actuele Documentatie en Compliance X 1.1 1.2* 1.3* 1.4*
DK Best Practices WUS   1.10 1.10 1.10 1.10
DK Best Practices EBMS2   3.1 3.1 3.2* 3.2
DK Best Practices Grote Berichten    3.1 3.1 3.1 3.1
DK Gebruik en achtergrond certificaten   1.5 1.5 1.5 1.5

Met een sterretje* is aangegeven welke onderdelen zijn gewijzigd in de release.  

Release 16 mei 19 - Wijziging Standaarddocumentatie

Overzicht van de wijzigingen

Wijzigingsverzoeken

Het Technisch Overleg Digikoppeling heeft goedkeuring verleend aan de volgende wijzigingen:

RFC# Ingediend wijzigingsverzoek Datum
2019* WUS: Signing 04-11-2018
2019-2 ebMS: Gebruik van SyncReplyMode verruimd. 07-02-2019

*.3.1 Digikoppeling_Koppelvlakstandaard_WUS_v3.7

Gewijzigde documenten

De volgende documenten zijn gewijzigd:

Digikoppeling actuele versie vorige versie
Digikoppeling_Koppelvlakstandaard_WUS 3.7 3.6
Digikoppeling_Koppelvlakstandaard_ebMS2 3.3 3.2
Digikoppeling_Best_Practices_ebMS2 3.2 3.1
Digikoppeling Overzicht Actuele Documentatie en Compliance 1.3 1.2

Wijzigingen per document

Digikoppeling Koppelvlakstandaard WUS v3.7

#

Locatie 

Oorspronkelijke tekst

Gewijzigd in

# RfC

Toelichting

1

2.4.2

P10

wsa:To

Dit wordt gebruikt om de endpoint vast te leggen waar het bericht naar toe dient te gaan.  Het element wsa:to is van het type wsa:AttributedURIType - een extensie op het xs:anyUri type- en dient gevuld te worden met een ‘Adres’ element. De waarde van het adres element kan hetzij een absolute URI zijn of

http://www.w3.org/2005/08/add ressing/anonymous. Optioneel kan het To-adres aangevuld te worden met een OIN door het gebruik van querystring parameters (e.g. http://serviceend-point?oin=xxxxxx). De waarde van de oin in het adres is het oin nummer van de ontvangende partij.

wsa:To

Dit wordt gebruikt om de endpoint vast te leggen waar het bericht naar toe dient te gaan. 

Het element wsa:to is van het type wsa:AttributedURIType - een extensie op het xs:anyUri type- en dient gevuld te worden met een ‘Adres’ element

(wsa:Address). De waarde van het adres element kan hetzij een absolute URI zijn of

http://www.w3.org/2005/08/addressing/ anonymous. Optioneel kan het To-adres aangevuld te worden met een OIN door het gebruik van querystring parameters

(e.g. http://service-end-

point?oin=xxxxxx). De waarde van de oin in het adres is het oin nummer van de ontvangende partij.

2019*

Toegevoegd

(wsa:Address)

2 2.4.2 p11 wsa:From WS-Addresing request headers wsa:RelatesTo  Indicates relationship to a prior message. Unused in this MEP, but could be included to facilitate longer running message exchanges wsa:From   WS-Addresing request headers wsa:RelatesTo  Indicates relationship to a prior message. Unused in this Message Exchange Pattern (MEP), but could be included to facilitate longer running message exchanges. 2019-1 Toegevoegd Message Exchange Pattern  
3 2.4.2 p11 WS-Addresing response headers wsa:To Y WS-Addresing response headers   wsa:To Y* … * Sommige platformen wijken op dit punt af van de Web Service Addresing 1.0 – Metadata standaard. Het wsa:To veld wordt bij synchrone SOAP verkeer actief uit het antwoordbericht gefilterd. Om hier vanuit de standaard aan tegemoet te komen mag bij het ontbreken van dit veld in het antwoordbericht door de ontvanger de anonymous waarde (http://www.w3.org/2005/08/addressing/ anonymous) worden aangenomen.   2019-1  
  2.4.2 p12 WS-Addresing response headers   wsa:MessageID Y   wsa:MessageID Y ** … ** Hiermee wordt afgeweken van wat de Web Services Addressing 1.0 – Metadata standaard voorschrijft. Volgens deze standaard is de MessageID in response optioneel. Bovenstaande properties kunnen in een aantal gevallen ook gespecificeerd worden door betreffende velden in de header weg te laten (3).   (3) 1 Zie WS-addressing 1.0- Core, paragraaf 2.1en paragraaf 3.2; zie ook BP 1.2 paragraaf 3.7.14.   2019-1  
  2.4.4 p14

WB004 Ondertekenen van bericht onderdelen SOAP:body, SOAP:headers (WS-Addressing headers en Timestamp) is verplicht bij toepassing van Endto-End beveiliging.

dient te worden gegenereerd op basis van de inhoud van het SignedInfo element.

WB004 Ondertekenen van bericht onderdelen SOAP:body, SOAP:headers (WSAddressing headers en Timestamp) is verplicht bij toepassing van End-to-End beveiliging. Van elk van deze onderdelen dient separaat een digest te worden berekend en te worden opgenomen in het SignedInfo element. De handtekening 2019-1  
  2.4.4 P15 WB010 Publieke sleutel dat gebruikt is voor het signing proces dient meegeleverd te worden met het bericht via  een ‘Direct security token’ reference.   Overwegingen: Het certificaat wordt in het bericht meegestuurd. Hiermee kan de ontvanger door middel van het meegeleverd certificaat de handtekening controleren. Het certificaat dient uiteraard wel vertrouwd te zijn via een truststore configuratie WB010 Publieke sleutel welke gebruikt is voor het signing proces dient meegeleverd te worden met het bericht via  een ‘Direct security token’ reference.     Overwegingen: Het certificaat wordt in het bericht meegestuurd. Hiermee kan de ontvanger door middel van het meegeleverd certificaat de handtekening controleren. Het certificaat dient uiteraard wel vertrouwd te zijn via een truststore configuratie waarin het PKIoverheid stamcertificaat alsmede de intermediair certificaten en Trusted Servicer Provider certificaten zijn opgenomen. Zie hiervoor https://cert.pkioverheid.nl/. (een vereiste voor veel platformen om de validatie van het bericht aan te vangen). 2019-1  
  2.4.4 P15 (nieuw) WB013 Indien WS-Security wordt toegepast, is het controleren van de signature door de ontvangende partij verplicht.   Overwegingen: Het ondertekenen van berichten is alleen zinvol als de ontvanger van het bericht ook daadwerkelijk de signature valideerd. Indien de validatie mislukt, dient het bericht afgewezen te worden en een foutmelding als antwoord te worden verstuurd. 2019-1  
  2.4.4 P15 (nieuw) WB014 Indien WS-Security wordt toegepast dient het responsebericht de signature van het requestbericht als onderdeel van het SignatureConfirmation element op te nemen (WS-Security 1.1).   Overwegingen: Door het herhalen van de ondertekening van het requestbericht kan de ontvanger van het responsebericht valideren dat het oorspronkelijke requestbericht in onaangetaste staat is ontvangen en verwerkt. 2019-1  

Digikoppeling Koppelvlakstandaard ebMS v3.3

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
1 Par 2.3/P9 Reliable Messaging: asynchrone uitwisseling met ontvangst bevestigingen en duplicaateliminatie door de ontvangende message handler Aan deze zin is een voetnoot toegevoegd: In bepaalde gevallen mag een acknowledgement synchroon verstuurd worden. Zie par 4.4 2019-2  
2 Par 2.3/P9 De berichtenuitwisseling is asynchroon: een business request wordt in een eigen synchrone HTTP request/response sessie verzonden, terwijl de acknowledgement en optionele business response via een separaat HTTP request/response sessie verzonden worden. De berichtenuitwisseling is in principe asynchroon: een business request wordt in een eigen synchrone HTTP request/response sessie verzonden, terwijl de acknowledgement en optionele business response via een separaat HTTP request/response sessie verzonden worden. In bepaalde gevallen (zie Fout! Verwijzingsbron niet gevonden.) mag een acknowledgement of een error synchroon verstuurd worden, Businessresponses worden altijd asynchroon, in een separaat HTTP sessie verzonden. 2019-2  
3 Par 3.1/P12 SyncReply Module [ebMS 2.0] Section 4.3 Best effort & Reliable Messaging & End-to-End Security SyncReply is never used in these profiles. All messages, including acknowledgments and error messages, are sent asynchronously.

SyncReply Module [ebMS 2.0] Section Fout! Verwijzingsbron niet gevonden. Opgesplitst in 3 kolommen:

Best effort
Never used in this profile

Reliable Messaging
Optional used in this profile. All messages, including acknowledgments and error messages, are sent asynchronously, with the exception of cases as described in par 4.4.1. Only in specific cases can MSH signals (acknowledgements, errors) sent synchronously. See 4.4.1 for conditions.

End-to-End Security
Optional in this profile. See profile Best Effort or profile Reliable Messaging for details

2019-2  
4 Par 3.1/P12 [Name and Reference]
Asynchronous messaging does not preclude fast response times, as is required to support interactive applications. Asynchronous messaging supports higher levels of scalability and supports scenarios where a response message may be sent minutes, hours or days after the initial request message. Asynchronous messaging may be combined transparently with store-and-forward intermediaries.
[Notes]
Asynchronous messaging does not preclude fast response times, as is required to support interactive applications. Asynchronous messaging supports higher levels of scalability and supports scenarios where a response message may be sent minutes, hours or days after the initial request message. Asynchronous messaging may be combined transparently with store-and-forward intermediary
2019-2 Tekst is ongewijzigd. De alinea is verplaatst naar de Notes
5 Par 3.2/P16 Mult-hop Module These profiles use asynchronous communication for business messages, acknowledgments and error messages. This protocol is therefore compatible with asynchronous, transparent, store-and-forward ebXML Messaging (or other SOAP-based) intermediaries. However, this document only specifies functionality between ebXML Message endpoints. (See also caveat in the section 'Reliable Messaging Module' in this chapter.) [verwijderd] 2019-2 Multi-hop wordt niet gebruik binnen Digikoppeling. Dan is deze toelichting over het gebruik van asynchronous messaging niet relevant.
6 Par 4.4.1/P40
Name and Reference
[ebMS 2.0] Section 4.3 SyncReply
Best effort & Reliable Messaging & End-to-End Security
Opgesplitst in 3 kolommen:
(zie #7)
   
7 Par 4.4.1/P40 Profiling (a) (leeg)

Best effort
Not applicable

Reliable Messaging
SyncReply is restricted to none (default) or mshSignalsOnly (on condition)

Condition for usage of msghSignalsOnly mode is:

  • both parties MSH are able to activate syncReplyMode=msghSignalsOnly see also [Best Practice]

End-to-End Security
See profile Best Effort or profile Reliable Messaging for details

   
8 Par 4.4.1/P40
Profiling (b)
If SyncReply mode is used, are MSH signals, business messages or both expected synchronously?
 (leeg)

Best effort
Not applicable

Reliable Messaging
If SyncReply mode used only MSH signals are expected synchronously

End-to-End Security
See profile Best Effort Reliable Messaging for details

   
9 Par 4.8.1/P50 In case Reliable messaging is used: This profile uses end-to-end reliable messaging. This allows the Digikoppeling to recover from any temporary processing failures at the level of intermediaries. Upcoming versions of the Digikoppeling may support store and forward ebXML intermediaries at an infrastructure level. The functionality of these intermediaries is likely be limited to fully transparent, asynchronous store-and-forward routing of ebXML Messages. In that case, no special processing is required of endpoints in the presence of any such intermediaries, as compared to direct point-to-point connections, other than supporting connection to/from the URL and client and server TLS authentication details for the intermediary rather than the “true” sender/recipient. In case Reliable messaging is used: This profile uses end-to-end reliable messaging. This allows the Digikoppeling to recover from any temporary processing failures at the level of intermediaries. Upcoming versions of the Digikoppeling may support store and forward ebXML intermediaries at an infrastructure level. The functionality of these intermediaries is likely be limited to fully transparent, asynchronous store-and-forward routing of ebXML Messages, with the exception of cases as described in par 4.4.1. In the default asynchronous case, no special processing is required of endpoints in the presence of any such intermediaries, as compared to direct point-to-point connections, other than supporting connection to/from the URL and client and server TLS authentication details for the intermediary rather than the “true” sender/recipient.    
10 6.1 Non- Normative References   Toegevoegd: [Best Practice] Digikoppeling Best Practices ebMS2 URL https://www.logius.nl/sites/default/files/public/bestanden/diensten/DigiKoppeling/Standaarden/Digikoppeling-Best-Practices-ebMS2.pdf    
11 Hele document   Een paar kleine typo’s verwijderd    

Digikoppeling Best Practices ebMS2 v3.2 (Niet Normatief)

Best Practice EB015 over SyncReply toegevoegd

Overzicht Releases

Document Normatief Release 23-07-2018 Release 21-08-2018 Release 16-05-2019
Wat is Digikoppeling   1.1.1 1.1.1. 1.1.1
DK Beheermodel en releasebeleid   1.5 1.5 1.5
DK Architectuur X 1.5.1 1.5.1 1.51
DK Koppelvlakstandaard WUS X 3.5 3.6 3.7*
DK Koppelvlakstandaard EBMS2 X 3.2 3.2 3.3*
DK Koppelvlakstandaard Grote Berichten X 3.2   3.2 3.2
DK Identificatie en Authenticatie X 1.4 1.4 1.4
DK Beveiliging standaarden en voorschriften X 1.1 1.1 1.1
DK Overzicht Actuele Documentatie en Compliance X 1.1 1.2 1.3*
DK Best Practices WUS   1.10 1.10 1.10
DK Best Practices EBMS2   3.1 3.1 3.2*
DK Best Practices Grote Berichten    3.1 3.1 3.1
DK Gebruik en achtergrond certificaten   1.5 1.5 1.5

Met een sterretje* is aangegeven welke onderdelen zijn gewijzigd in de release.

Release 21 aug 18 - Wijziging Standaarddocumentatie

Overzicht van de wijzigingen

Wijzigingsverzoeken

# Locatie  Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
1 2.4.2 P10 wsa:To Dit wordt gebruikt om de endpoint vast te leggen waar het bericht naar toe dient te gaan.  Het element wsa:to is van het type wsa:To Dit wordt gebruikt om de endpoint vast te leggen waar het bericht naar toe dient te gaan.  Het element wsa:to is van het type 2018-1  

Het Technisch Overleg Digikoppeling heeft goedkeuring verleend aan de volgende wijzigingen:

RFC# Ingediend wijzigingsverzoek Datum
2018-1 WUS: OIN in de WSA:To en WSA:From header-elementen. 04-01-2018

Gewijzigde documenten

De volgende documenten zijn gewijzigd:

Digikoppeling actuele versie vorige versie
Digikoppeling_Koppelvlakstandaard_WUS 3.6 3.5

Wijzigingen per document

Digikoppeling Koppelvlakstandaard WUS v3.6

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
1 2.4.2 P10

wsa:To
Dit wordt gebruikt om de endpoint vast te leggen waar het bericht naar toe dient te gaan. Het element wsa:to is van het type wsa:AttributedURIType - een extensie op het xs:anyUri type- en dient gevuld te worden met een ‘Adres’ element. De waarde van het adres element kan hetzij een absolute URI zijn of http://www.w3.org/2005/08/addr essing/anonymous.  

wsa:To
Dit wordt gebruikt om de endpoint vast te leggen waar het bericht naar toe dient te gaan. Het element wsa:to is van het typ wsa:AttributedURIType - een extensie op het xs:anyUri type- en dient gevuld te worden met een ‘Adres’ element. De waarde van het adres element kan hetzij een absolute URI zijn of http://www.w3.org/2005/08/addressing/ anonymous. Optioneel kan het To-adres aangevuld te worden met een OIN door het gebruik van querystring parameters (e.g. http://service-end- point?oin=xxxxxx). De waarde van de oin in het adres is het oin nummer van de ontvangende partij.      

2018-1  
2 2.4.2  p10 wsa:From
Het gebruik van wsa:From is optioneel voor synchrone berichten voor bevragingen. De waarde van dit veld wordt gebruikt om aan te geven waar het bericht vandaan komt. De wsa:From is van het type wsa:EndPointReferenceType en dient gevuld te worden met een ‘Adres’ element. De waarde van het adres element kan hetzij een absolute URI zijn of http://www.w3.org/2005/08/addr essing/anonymous.

wsa:From
Het gebruik van wsa:From is optioneel voor synchrone berichten voor bevragingen. De waarde van dit veld wordt gebruikt om aan te geven waar het bericht vandaan komt. De wsa:From is van het type wsa:EndPointReferenceType en dient gevuld te worden met een ‘Adres’ element (wsa:Address). De waarde van het adres element kan hetzij een absolute URI zijn of http://www.w3.org/2005/08/addressing/ anonymous. Optioneel kan het From-adres aangevuld te worden met een OIN door het gebruik van querystring parameters (e.g. http://service-end-point?oin=xxxxxx). De waarde van de oin in het adres is het oin nummer van de verzendende partij.

2018-1  

Overzicht Releases

Document Normatief Release 19-10-2017 Release 23-07-2018 Release 21-08-2018
Wat is Digikoppeling   1.1 1.1.1* 1.1.1.
DK Beheermodel en releasebeleid   1.5 1.5 1.5
DK Architectuur X 1.5 1.5.1* 1.5.1
DK Koppelvlakstandaard WUS X 3.5 3.5 3.6*
DK Koppelvlakstandaard EBMS2 X 3.2 3.2 3.2
DK Koppelvlakstandaard X 3.2 3.2 3.2
Grote Berichten        
DK Identificatie en Authenticatie X 1.4 1.4 1.4
DK Beveiliging standaarden en voorschriften X 1.1 1.1 1.1
DK Overzicht  Actuele Documentatie en Compliance X 1.0 1.1* 1.2*
DK Best Practices WUS   1.10 1.10 1.10
DK Best Practices EBMS2   3.1 3.1 3.1
DK Best Practices Grote Berichten    3.1 3.1 3.1
DK Gebruik en achtergrond certificaten   1.5 1.5 1.5

Met een sterretje* is aangegeven welke onderdelen zijn gewijzigd in de release.

Release 23 jul 18 - Wijziging Standaarddocumentatie

Overzicht van de wijzigingen

Wijzigingsverzoeken

Op 25 mei 2018 stemde het OBDO in met het aanpassen van de manier van versioneren van de Digikoppeling standaard, versionering en versiebeheer wordt uitsluitend op niveau van de deelspecificaties gevoerd, zie Forum Standaardisatie.

Gewijzigde documenten

De volgende documenten zijn gewijzigd:

Digikoppeling actuele versie vorige versie
Digikoppeling Overzicht Actuele Documentatie en Compliance 1.1 1.0
Digikoppeling Architectuur 1.5.1 1.5
Wat is Digikoppeling 1.1.1 1.1

Wijzigingen per document

Digikoppeling Overzicht Actuele Documentatie en Compliance 1.1

Het overzicht actuele documentatie is aangepast met de nieuwe versienummers van de gewijzigde documenten.

Digikoppeling Architectuur 1.5.1

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
1 P12 - Toegevoegd:
Voor de Digikoppeling standaard is in 2018 de versionering op het hoofdniveau beëindigd. Er zal alleen nog worden gerefereerd aan de Digikoppeling standaard en de versionering van de verschillende onderdelen wordt op documentniveau bijgehouden.  
-  

Wat is Digikoppeling 1.1.1

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
1 P28 -

Toegevoegd:
Voor de Digikoppeling standaard is in 2018 de versionering op het hoofdniveau beëindigd. Er zal alleen nog worden gerefereerd aan de Digikoppeling standaard en de versionering van de verschillende onderdelen wordt op documentniveau bijgehouden.

-  

Overzicht Releases

Wat is Digikoppeling   1.1 1.1.1*
DK Beheermodel en releasebeleid   1.5 1.5
DK Architectuur X 1.5 1.5.1*
DK Koppelvlakstandaard WUS X 3.5 3.5
DK Koppelvlakstandaard EBMS2 X 3.2 3.2
DK Koppelvlakstandaard Grote Berichten X 3.2 3.2
DK Identificatie en Authenticatie X 1.4 1.4
DK Beveiliging standaarden en voorschriften X 1.1 1.1
DK Overzicht Actuele Documentatie en Compliance X 1.0 1.1*
DK Best Practices WUS   1.10 1.10
DK Best Practices EBMS2   3.1 3.1
DK Best Practices Grote Berichten    3.1 3.1
DK Gebruik en achtergrond certificaten   1.5 1.5

Met een sterretje* is aangegeven welke onderdelen zijn gewijzigd in de release.

Release 18 okt 17 - Wijziging Standaarddocumentatie

Overzicht van de wijzigingen

Algemene tekst en structuur verbeteringen

De volgende wijzigingen zijn in alle documenten doorgevoerd:

  1. Gebruik van aanduiding ebMS2 i.p.v. ebMS
  2. Gebruik van aanduiding CPA Register i.p.v. CPA Creatieregister
  3. Update figuur structuur Digikoppeling documentatie
  4. Toevoegen overzicht documentatie
  5. Actualiseren teksten o.b.v. Digikoppeling versie 3.0 (zonder ws-rm)

Wijzigingsverzoeken

Het Technische Overleg Digikoppeling heeft  goedkeuring verleend aan de volgende wijzigingsverzoeken.

RFC# Ingediend wijzigingsverzoek Datum
1 Ebms: Verlichten restrictie 1st payload type XML 01-02-2017

Gewijzigde documenten

De volgende documenten zijn gewijzigd:

Digikoppeling_Koppelvlakstandaard_WUS 3.5 3.4 2.7
Digikoppeling_Koppelvlakstandaard_ebMS2 3.2 3.1 2.7
Digikoppeling_Koppelvlakstandaard_GB 3.2 3.1 1.4
       
Digikoppeling_Beheermodel 1.5 1.4 1.4
Digikoppeling_Beveiligingsstandaarden_en_voorschrifte n 1.1 1.0 1.0
Digikoppeling_Identificatie_en_Authenticatie 1.4 1.3 1.3
Digikoppeling_Gebruik_en_achtergrond_certificaten 1.5 1.4 1.4
       
Digikoppeling_Best_Practices_ebMS2 3.1 3.0 1.6
Digikoppeling_Best_Practices_GB 3.1 3.0 1.1
Digikoppeling_Best_Practices_WUS 1.10 1.9 1.4

Wijzigingen per document

2.1.1 Digikoppeling Koppelvlakstandaard ebMS2 v3.2.docx

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
1 5.5 p62 (Section 2.1.4) How many Payload Containers must be present?    Messages other than standalone receipt acknowledgement messages and error messages  must contain one container with the actual xml payload and optional one or more containers for the attachments (one container for each attachment). This option is provided to facilitate bridging to other protocols at the enterprise level that may or may not support multiple payloads natively.  If there is only and only one container, this profile (section) is Digikoppeling 1.0 and Digikoppeling 1.1 compliant.   (Section 2.1.4) How many Payload Containers must be present?    Messages may contain one or more payload containers   1 Restricitie 1st payload type XML vervalt
2 5.5 p62 What is the structure and content of each container? [List MIME Content-Types and other process-specific requirements.] Are there restrictions on the MIME types allowed for attachments?    The first payload container must be of type “application/xml”. I.e. for the Digikoppeling the first container consists of a single XML business document (the Digikoppeling 'payload').  If there are additional containers, each container will get a MIME type reflecting the type of the Digikoppeling 'attachment' it contains.   What is the structure and content of each container? [List MIME Content-Types and other process-specific requirements.] Are there r estrictions on the MIME types allowed for attachments?    Each payload container will get a MIME type reflecting the type of the ‘content’ it contains. 1 Restrictie 1st payload  type XML vervalt

Release 26 mei 16 - Wijziging Standaarddocumentatie Digikoppeling 2.0 en 3.0

Status van de Wijzigingen

De Afnemersraad Stelseldiensten heeft op 19 mei 2016 de in deze release notes vermelde documenten vastgesteld.

Overzicht van de wijzigingen

Het Technische Overleg Digikoppeling heeft op 15 februari 2016 goedkeuring verleend aan de volgende wijzigingsverzoeken.

RFC# Ingediend wijzigingsverzoek Datum ingediend
1 Verzocht wordt om beveiligingsstandaarden op te nemen in een apart document waarin alleen de actuele versies van de TLS standaard, de SHA standaard en ciphers staan. De koppelvlakspecificaties kunnen naar dit document verwijzen. 11-6-2015
2 Verzocht wordt om requirement “4.1.8 Profile Requirement Item: Timestamp” uit de koppelvlakspecificatie ebMS te verwijderen omdat het formaat van de Timestamp niet configureerbaar is. 7-9-2015
3 Verzocht wordt om in DK 3.0 WUS KVS in paragraaf 2.4.2 het type van de wsa:to aan te passen naar anyURI (in plaats van EndpointReference)  om daarmee onderliggende standaarden te volgen. 17-9-2015
4 Bij het samenstellen van het nieuwe Digikoppeling beveiligingsvoorschrift zijn ook referenties naar (wettelijke)regelingen en internationale standaarden bekeken en indien nodig up-to-date gebracht. 4-4-2016

Bij de uitvoering van dit wijzigingsverzoek is geconstateerd dat in de Digikoppeling Documentatie nog verwezen werd naar de SHA-1 standaard tbv signing en encryptie. SHA-1 is echter inmiddels niet meer veilig voor dit doel. Bij het opstellen van het Digikoppeling Beveiligingsvoorschrift is daarom de volgende wijziging doorgevoerd:

RFC# Ingediend wijzigingsverzoek Datum ingediend
5 SHA-1 wordt gezien als een zwakke cipher voor signing en deze zal in de loop van dit jaar niet langer door de gangbare browsers ondersteund worden.
In de beveiligingsrichtlijnen voor Transport Security van het NCSC wordt het gebruik van  SHA voor Voor het genereren van een certificaathandtekening onvoldoende bestempeld. Op de “Gangbare Standaarden” lijst van het Forum Standaardisatie wordt naar SHA-2 verwezen.
4-4-2016

Naar aanleiding van deze verzoeken zijn de volgende documenten uit de Digikoppeling Standaard gewijzigd:

Digikoppeling 2.0

  • Digikoppeling_2.0_Architectuur_v1.4.docx
  • Digikoppeling_2.0_Koppelvlakstandaard_WUS_v2.7.docx
  • Digikoppeling_2.0_Koppelvlakstandaard_ebMS_v2.7.docx
  • Digikoppeling_2.0_Koppelvlakstandaard_GB_v1.4.docx

Digikoppeling 3.0

  • Digikoppeling_3.0_Architectuur_v1.3.docx
  • Digikoppeling_3.0_Koppelvlakstandaard_ebMS_v3.1.docx
  • Digikoppeling_3.0_Koppelvlakstandaard_GB_v3.1.docx
  • Digikoppeling_3.0_Koppelvlakstandaard_WUS_v3.4.docx

Digikoppeling 2.0 en 3.0

  • Digikoppeling_Identificatie_en_Authenticatie_v1.3.docx
  • Digikoppeling_Gebruik_en_achtergrond_certificaten_v1.4.docx
  • Digikoppeling_Beheermodel_v1.4.docx
  • Digikoppeling_Beveiligingsstandaarden_en_voorschriften_v2.docx

Daarnaast zijn de XML berichtvoorbeelden uit de Digikoppeling koppelvlakstandaarden WUS 2.0 en 3.0 verwijderd. Deze voorbeelden zullen worden gepubliceerd in een apart document en worden op een later  moment opgeleverd.

Wijzigingen per document

Digikoppeling 2.0

Digikoppeling 2.0 Architectuur v1.4.docx

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
1 7.2 p28 In Digikoppeling   is ervoor gekozen om dat certificaat te gebruiken op het niveau van het communicatie KANAAL (TLS) en (nog) niet op het niveau van het BERICHT (XMLDsigof bijv. x509 token). Dit is in detail uitgewerkt in ' Digikoppeling Identificatie en Authenticatie'. In Digikoppeling is ervoor gekozen om dat certificaat te gebruiken op het niveau van het communicatie KANAAL (TLS) en ook op het niveau van het BERICHT (XMLDsigof bijv. x509 token). Dit is in detail uitgewerkt in 'Digikoppeling Identificatie en Authenticatie' en 'Digikoppeling Beveiligingsstandaarden en voorschriften'. 4  
2 7.3 p28 Zowel de koppelvlakstandaard van ebMS als van WUS maken gebruik van TLS/SSL v3 (tweezijdig) voor encryptie van berichten. Als in de toekomst versleuteling van de payload opgenomen wordt in de standaarden, zal dat in beide gevallen gebeuren op basis van XML Encryption of mogelijke andere toekomstige standaarden. Zowel de koppelvlakstandaard van ebMS als van WUS maken gebruik van TLS  (tweezijdig) voor encryptie van berichten. Versleuteling van de payload is sinds Digikoppeling 2.0 opgenomen in de koppelvlakstandaarden op basis van XML Encryption of mogelijke andere toekomstige standaarden. Dit is in detail uitgewerkt in ‘Digikoppeling Beveiligingsstandaarden en voorschriften’. 1, 4  

Digikoppeling 2.0 Koppelvlakstandaard WUS v2.7.docx

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
3 1.2p4  

Standaardenplaat aangepast

4  
4

2.11p6

3.1p21

Bijl.1-4

  De XML voorbeelden zijn verplaatst naar een nieuw nog te publiceren document 4  
5 2.3p11
2.4.4p16
Verwijzing naar specifieke TLS versies
Voorschriften WT001, WT003
Verwijzing naar [Digikoppeling beveiligingsstandaarden en voorschriften] 1  
6 2.4.4p16 Aangezien er meerdere WS-Addressing specificaties zijn, die onder meer verschillende namespaces kunnen hebben, is er voor gekozen om alleen de specificatie van 2005/08 (http://www.w3.org/TR/2005/C R-ws-addr-core-20050817/) of van 2006/05 (http://www.w3.org/TR/wsaddr-core/ ) verplicht te stellen in de berichten binnen het Digikoppeling domein. Hieronder wordt de toepassing van de verschillende velden toegelicht.

Aangezien er meerdere WS-Addressing specificaties zijn, die onder meer verschillende namespaces kunnen hebben, is er voor gekozen om alleen de specificatie van 2006/05 (http://www.w3.org/TR/wsaddr-core/ ) verplicht te stellen in de berichten binnen het Digikoppeling domein. Hieronder wordt de toepassing van de verschillende velden toegelicht.

4 Verwijzing naar candidate recommendation verwijderd
7 2.4.2p17 WB007 Technische gegevens ten behoeve van ondertekenen:

DigestMethodAlgorithm SHA-1  (http://www.w3.org/2000/09/x mldsig#sha1) SignatureMethodAlgorithm
SHA-1 (http://www.w3.org/2000/09/x mldsig#hmac-sha1 of http://www.w3.org/2000/09/x mldsig#rsa-sha1)

WB007 Technische gegevens ten behoeve van ondertekenen:

DigestMethodAlgorithm zie [Digikoppeling beveiligingsstandaarden en voorschriften]   
SignatureMethodAlgorithm zie [Digikoppeling beveiligingsstandaarden en voorschriften]

4,5

Verplaatst naar Digikoppeling beveiligingsstandaarden en voorschriften verwijzingen naar SHA-1 vervangen door SHA-2

8  

WB008 Technische gegevens ten behoeve van versleutelen:

Data Encryption Algorithms 3DES (http://www.w3.org/2001/04/xmlenc#tripledes-cbc)
of
AES128 (http://www.w3.org/2001/04/x mlenc#aes128-cb)
of  
AES256 (http://www.w3.org/2001/04/x mlenc#aes256-cbc) Key Transport Algorithms RSA-1_5 (http://www.w3.org/2001/04/x mlenc#rsa-1_5)  
of  
RSA-OAEP (http://www.w3.org/2001/04/x mlenc#rsa-oaep-mgf1p)

WB008 Technische gegevens ten behoeve van versleutelen:
 
Data Encryption Algorithms zie [Digikoppeling beveiligingsstandaarden en voorschriften]
Key Transport Algorithms zie [Digikoppeling beveiligingsstandaarden en voorschriften]
4 Verplaatst naar  Digikoppeling beveiligingsstandaard en en voorschriften

Digikoppeling 2.0 Koppelvlakstandaard ebMS v2.7.docx

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
9 1.2p5   Standaardenplaat aangepast 4  
10 2.5p12 4.2.3p37 4.2.6p38 4.11.4p6 Verwijzing naar specifieke TLS versies Voorschriften 4.2.3, 4.2.6, 4.11.4 verwijzing naar [Digikoppeling beveiligingsstandaarden en voorschriften] 1  
11 2.4p10 4.1.5p25 4.4.1p typo in naam 1.1.1 MessageId en RefTo1.1.1  MessageId gewijzigd in MessageId, RefToMessageId 4  
12 43
4.1.5p25
[RFC 2822] [RFC 5322] 4  
13 4.2.1p39 Payload confidentiality is optional. Whenever used, the [FIPS 179] standard (AES 256cbc) is used by the [XML Encryption]. Payload confidentiality is optional.  The [Digikoppeling beveiligingsstandaarden en voorschriften] describes what security standard must be used.  4 FIPS 179 moet zijn FIPS 197
14 4.2.1p33 Verwijzing naar SHA-1 verwijzing naar [Digikoppeling beveiligingsstandaarden en voorschriften] 5 verwijzingen naar SHA-1 vervangen door SHA-2
15 5.5p72 Message Payload and Flow Profile (zonder paragraaf aanduiding) 5.5 Message Payload and Flow Profile 4 paragraaf aanduiding (5.5) toegevoegd
16 6.1 Normative and Non Normative Referenties Sommige niet meer gebruikte referenties verwijderd.  Referenties bijgewerkt en paden aangepast 4  
17 4.1.8p28 4.1.8p29 Timestamps must include the ‘Z’ (UTC) identifier. Requirement has been removed    2 Item is als leeg item gehandhaafd  om doornummering niet om te gooien

Digikoppeling 2.0 Koppelvlakstandaard GB v1.4.docx

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
18 1.2p4   Standaardenplaat aangepast 4  
19 4.2p14 e.v.   Verwijzing naar specifieke TLS versies Voorschriften GB006, GB007 verwijzing naar [Digikoppeling beveiligingsstandaarden en voorschriften] 1  
20 5.1p18 Referenties Sommige niet meer gebruikte referenties verwijderd.  Referenties bijgewerkt en paden aangepast 4  

Digikoppeling 3.0

Digikoppeling 3.0 Koppelvlakstandaard ebMS v3.1.docx

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
20 1.2p5   Standaardenplaat aangepast 4 Plaat voor DK3
21 2.5p12 4.2.3p37 4.2.6p38 4.11.4p6 Verwijzing naar specifieke TLS versies Voorschriften 4.2.3, 4.2.6, 4.11.4 verwijzing naar [Digikoppeling beveiligingsstandaarden en voorschriften] 1  
22 2.4p10 4.1.5p25 4.4.1p43 typo in naam 1.1.1 MessageId en RefTo1.1.1  MessageId gewijzigd in MessageId, RefToMessageId 4  
23 4.1.5p25 [RFC 2822] [RFC 5322] 4  
24 4.2.1p39 Payload confidentiality is optional. Whenever used, the [FIPS 179] standard (AES 256cbc) is used by the [XML Encryption]. Payload confidentiality is optional.  The [Digikoppeling beveiligingsstandaarden en voorschriften] describes what security standard must be used.  4 FIPS 179 moet zijn FIPS 197
25 4.2.1p33 Verwijzing naar SHA-1 verwijzing naar [Digikoppeling beveiligingsstandaarden en voorschriften] 5 verwijzingen naar SHA-1 vervangen door SHA-2
26 5.5p72 Message Payload and Flow Profile (zonder paragraaf aanduiding) 5.5 Message Payload and Flow Profile 4 paragraaf aanduiding (5.5) toegevoegd
27 6.1 Normative and Non Normative Referenties Sommige niet meer gebruikte referenties verwijderd.  Referenties bijgewerkt en paden aangepast 4  
28 4.1.8p28 4.1.8p29 Timestamps must include the ‘Z’ (UTC) identifier. Requirement has been removed 2 Item is als leeg item gehandhaafd  om doornummering niet om te gooien

Digikoppeling 3.0 Koppelvlakstandaard GB v3.1.docx

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
29 1.2p4   Standaardenplaat aangepast 4  
30 4.2p14 e.v.   Verwijzing naar specifieke TLS versies Voorschriften GB006, GB007 verwijzing naar [Digikoppeling beveiligingsstandaarden en voorschriften] 1  
31 5.1p18 Referenties Sommige niet meer gebruikte referenties verwijderd.  Referenties bijgewerkt en paden aangepast 4  

Digikoppeling 3.0 Koppelvlakstandaard WUS v3.4.docx

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
32 1.2p4 Oude plaat Standaardenplaat aangepast 4  
33 2.11p6 3.1p21 Bijl.1-4 XML voorbeelden De XML voorbeelden zijn verplaatst naar een nieuw nog te publiceren document 4   
34 2.3p11 2.4.4p16 Verwijzing naar specifieke TLS versies Voorschriften WT001, WT003 verwijzing naar [Digikoppeling beveiligingsstandaarden en voorschriften] 1  
35 2.4.4p16 Aangezien er meerdere WS- Addressing specificaties zijn, die onder meer verschillende namespaces kunnen hebben, is er voor gekozen om alleen de specificatie van 2005/08 (http://www.w3.org/TR/2005/C R-ws-addr-core-20050817/) of van 2006/05 (http://www.w3.org/TR/wsaddr-core/ ) verplicht te stellen in de berichten binnen het Digikoppeling domein. Hieronder wordt de toepassing van de verschillende velden toegelicht. Aangezien er meerdere WS- Addressing specificaties zijn, die onder meer verschillende namespaces kunnen hebben, is er voor gekozen om alleen de specificatie van 2006/05 (http://www.w3.org/TR/wsaddr-core/ ) verplicht te stellen in de berichten binnen het Digikoppeling domein. Hieronder wordt de toepassing van de verschillende velden toegelicht. 4 verwijzing naar candidate recommendation verwijderd
36 2.4.2p17 WB007 Technische gegevens ten behoeve van ondertekenen: … DigestMethodAlgorithm SHA-1  (http://www.w3.org/2000/09/x mldsig#sha1) SignatureMethodAlgorithm SHA-1 (http://www.w3.org/2000/09/x mldsig#hmac-sha1 of http://www.w3.org/2000/09/x mldsig#rsa-sha1) WB007 Technische gegevens ten behoeve van ondertekenen: … DigestMethodAlgorithm zie [Digikoppeling beveiligingsstandaarden en voorschriften]   SignatureMethodAlgorithm zie [Digikoppeling beveiligingsstandaarden en voorschriften]   4, 5 Verplaatst naar Digikoppeling beveiligingsstandaard en en voorschriften   verwijzingen naar SHA-1 vervangen door SHA-2
37   WB008 Technische gegevens ten behoeve van versleutelen:   Data Encryption Algorithms 3DES (http://www.w3.org/2001/04/x mlenc#tripledes-cbc) of AES128 (http://www.w3.org/2001/04/x mlenc#aes128-cb) of  AES256 (http://www.w3.org/2001/04/x mlenc#aes256-cbc) Key Transport Algorithms RSA- 1_5 (http://www.w3.org/2001/04/x mlenc#rsa-1_5)  of  RSA-OAEP (http://www.w3.org/2001/04/x mlenc#rsa-oaep-mgf1p) WB008 Technische gegevens ten behoeve van versleutelen:   Data Encryption Algorithms zie [Digikoppeling beveiligingsstandaarden en voorschriften] Key Transport Algorithms zie [Digikoppeling beveiligingsstandaarden en voorschriften]       " 4 verplaatst naar  Digikoppeling beveiligingsstandaard en en voorschriften
38 2.4.2/15 De wsa:To is van het type wsa:EndPointReferenceType en dient gevult te worden met een ‘Adres’ element. Het element wsa:to is van het type wsa:AttributedURIType - een extensie op het xs:anyUri type- en dient gevuld te worden met een ‘Adres’ element.  3  
39 2.4.2/15 De elementen wsa:To, wsa:ReplyTo en wsa:From zijn allen van de type ‘wsa:EndPointReferenceType

De elementen wsa:ReplyTo en wsa:From zijn beiden van de type ‘wsa:EndPointReferenceType’. 

Het EndPointReferenceType stelt enkel het element ‘Address’ verplicht. De overige velden van EndPointReferenceType zijn optioneel en zijn om compatibiteitsredenen niet toegestaan binnen Digikoppeling. Voor wsa:to komt deze restrictie dus te vervallen

3  
40 2.4.2/15 verwijzing naar candidate version verwijderd (https://www.w3.org/TR/2005/ CR-ws-addr-core-20050817/) https://www.w3.org/TR/wsaddr-core/ 4   
41 2.4.3/16 idem idem 4  
42 2.4.3 verwijzing naar SHA-1 en XMLDSIG  verwijderd en verplaatst naar Digikoppeling beveiligingsstandaarden en voorschriften 5  
43 2.4.3 SHA-1 (http://www.w3.org/2000/09/x mldsig#hmac-sha1 of http://www.w3.org/2000/09/x mldsig#rsa-sha1) Verwijderd, vervangen door SHA-2 en verplaatst naar Digikoppeling beveiligingsstandaarden en voorschriften 5  
44 2.4.3 3DES (http://www.w3.org/2001/04/x mlenc#tripledes-cbc) of AES128 (http://www.w3.org/2001/04/x mlenc#aes128-cbc) of  AES256 (http://www.w3.org/2001/04/x mlenc#aes256-cbc) verwijderd en verplaatst naar Digikoppeling beveiligingsstandaarden en voorschriften 4,5  
44 2.4.3   Opgenomen als referenties: RSA-1_5 (http://www.w3.org/2001/04/x mlenc#rsa-1_5)  of  RSA-OAEP (http://www.w3.org/2001/04/x mlenc#rsa-oaep-mgf1p    

Digikoppeling 3.0 Architectuur v1.3.docx

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
45   Geen inhoudelijke uitleg beveiliging/security/TLS/SHA/PKI/referenties ‘Digikoppeling Beveiligingsstandaarden en voorschriften en plaat met documenten aanpassen    

Digikoppeling 2.0 en 3.0

Digikoppeling Identificatie en Authenticatie v1.3.docx

NB: er is geen aparte RFC maar gaat om verouderde teksten die zijn geactualiseerd.

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
46 7.1/28 Zolang dat nog niet het geval is, zal voor gebruik op Digikoppeling de gewenste identiteit vastgelegd worden binnen Digikoppeling in het Digikoppeling Service Register. Zolang dat nog niet het geval is, zal voor gebruik op Digikoppeling de gewenste identiteit vastgelegd worden binnen het OIN register, onderdeel van het Digikoppeling Service Register. 4  
47 Bijlage 1: WBP/17 bijlage WBP 1 verwijderd ivm verouderde en niet relevante tekst (WBP is gewijzigd) 4  
48 1.2/4 Dit document gaat over de bedrijfsarchitectuur. Dit document gaat over de bedrijfsarchitectuur op landelijk niveau, en specifiek over de identificatie en authenticatie van organisaties 4  
49 1.3/4   Dit document is onderdeel van de Digikoppeling standaarden. (inclusief plaat) 4  
50 2.0/6 Als een overheidsorganisatie Als een (overheids)organisatie 4  
51 2.0/6 NORA principe P5  stelt: Burgers, bedrijven en maatschappelijke instellingen beschikken over één identiteit die bruikbaar is voor alle contacten met organisaties in het publieke domein en die afhankelijk van de soort dienstverlening ook nodig is en gevraagd moet worden. Dit ongeacht de keuze voor een kanaal. Een en ander komt neer op één administratieve identiteit (één identificatienummer). Deze administratieve identiteit dient afgebeeld te worden op een (ook digitaal toepasbaar) identiteitsbewijs. vervangen door AP37 (tabel) 4  
52 2.0/6 Dit principe moet ook van toepassing zijn op de overheidsorganisaties. Dit principe is ook van toepassing op (overheids)organisaties.  4  
53 5.0/15 De inhoud van het NHR is (ten aanzien van overheidsorganisaties) nog onzeker. De inhoud van het HR is door de Wet op het Handelsregister uitgebreid met rechtspersonen met een publieke taak. 4  
54 5.0/15 Het niveau rechtspersoon met als identificatienummer het Finummer. Het NHR heeft aangegeven, dat dat niveau, en dus dat nummer, in principe het meest geschikt is om voor identificatie op Digikoppeling te gebruiken. Het niveau rechtspersoon met als identificatienummer het Rechtspersonen en Samenwerkingsverbanden Identificatie Nummer (RSIN). Dit is inhoudelijk gelijk aan het Fiscaal-nummer. Het HR heeft aangegeven, dat dat niveau, en dus dat nummer, in principe het meest geschikt is om voor identificatie op Digikoppeling te gebruiken. 4  
55 Bijlage 1/17 Bijlage 1 WBP is vervallen  Nieuwe bijlage OIN en HRN) 4  
56 Bijlage 1/17 Logius maakt voor overheidsorganisaties primair gebruik van het fiscale nummer van de Belastingdienst dat ook is/wordt opgenomen in het NHR. In die gevallen waar een overheidsorganisatie nog geen fiscaal nummer heeft, kan worden uitgeweken naar alternatieven. Logius maakt voor overheidsorganisaties primair gebruik van het RSIN uit het HR. In die gevallen waar een overheidsorganisatie nog geen RSIN heeft, kan worden uitgeweken naar alternatieven. 4  
57 Bijlage 1/17 Prefix 00000001 Fi-nummer van Belastingdienst (9 posities). Dit wordt het RSIN uit het NHR. Prefix 00000001: RSIN uit het Handelsregister (9 posities) 4  
58 Bijlage 1/17 Prefix 00000005: Niet toegewezen (DigiD) Prefix 00000005: Niet toegewezen  4  
59 Bijlage 1/17 Prefix 00000006: Reservering (vestigingsnummer KvK)  Prefix 00000006: Niet toegewezen  4  
60 Bijlage 1/17 Prefix 00000007: Niet toegewezen (BRIN) Prefix 00000007: Gereserveerd voor BRIN 4  
61 Bijlage 1/17 Het Fi-nummer (RSIN) wordt opgegeven door de aanvrager en bij Belastingdienst (dan wel in het NHR) gecontroleerd door Logius Het RSIN wordt opgegeven door de aanvrager en bij het HR gecontroleerd door Logius 4  

Digikoppeling Gebruik en achtergrond certificaten v1.4.docx

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
62 1.2/4 Achtergrond Een belangrijk aspect voor beveiliging van Digikoppeling is de juiste identificatie, authenticatie en autorisatie van organisaties. Digikoppeling maakt hiervoor gebruik van een PKI-infrastructuur met certificaten. Voor Digikoppeling is daarbij gekozen om certificaten toe te passen die voldoen aan de eisen van PKIoverheid Achtergrond. Een belangrijk aspect voor beveiliging van Digikoppeling is de juiste identificatie, authenticatie en autorisatie van organisaties. Voor Digikoppeling is daarbij gekozen om certificaten toe te passen die voldoen aan de eisen van PKIoverheid. 1  
63 1.4 (nieuw)/4   Wijzigingen tov versie 1.3.1 1  
64 1.6 (was 1.5) Samenhang met andere documenten (tabel). Alle DK documenten plus PKIoverheid. alinea verwijderd en hernoemd Referenties  1  
65 2 Ontwerpen van de aansluiting op Digikoppeling met een Digikoppeling adapter (hoofdstuk 2).
  • Uitleg over PKIoverheid (hoofdstuk 2)
  • Ontwerpen van de aansluiting op Digikoppeling met een Digikoppeling adapter (hoofdstuk 3).
1  
66 2.2/7 Digikoppeling identificeert organisaties zoveel mogelijk in lijn met de Staatsalmanak. Voor Digikoppeling is van belang of organisatie(onderdelen) taken hebben in een wettelijk kader en hun bestuurders tekenbevoegd zijn. Soms identificeert Digikoppeling daarom onderdelen van organisaties. Digikoppeling identificeert organisaties zoveel mogelijk aan de hand van OIN. Zie Digikoppeling Identificatie en Authenticatie.     
67 2.2/7 Voor de unieke identificatie en authenticatie van deze organisaties is er door PKIoverheid gekozen (zie PKIoverheid Programma van Eisen 3b) om het OIN toe te voegen aan een PKIoverheid certificaat in het zogenaamde Subject.serialNumber-veld. Voor de unieke identificatie en authenticatie van deze organisaties wordt het OIN opgenomen in een PKIoverheid certificaat in het zogenaamde Subject.serialNumber-veld door de CSP. Voetnoot: Indien er sprake is van een twintigcijferig nummer is dit altijd het OIN (of HRN).     
68 nieuw hoofdstuk 2   nieuw hoofdstuk met Inleiding PKIoverheid certificaten    
69 nieuw hoofdstuk 2        
70 5.2 (was 4.2)/12 Achtergrond Beveiliging van de privésleutel kan plaatsvinden door deze op een smartcard (in PKI-termen een Secure User Device of afgekort SUD) te plaatsen. Een dergelijke fysieke beveiliging wordt vaak gecombineerd met een userid/password. Als alternatief kan de privésleutel ook in een password-beveiligde keystore opgeslagen worden. De eerste optie (SUD) heeft de voorkeur van PKIoverheid. Er zijn extra maatregelen nodig als er geen SUD gebruikt wordt. Het programma van eisen  dat PKIoverheid aan CSP's oplegt bevat de verplichting aan CSP's om over de juiste beveiliging van sleutels door gebruikers te waken inclusief de mogelijkheid tot audit (zie kader).     staat niet meer in PvE van PKIoverheid dus alinea en kader zijn verwijderd. Kader verwees naar een oude versie van PvE van PKIo en is in zijn geheel verwijderd.     
71 7.3.2/21   Nieuw: 7.3.2 TLS Offloading Door het gebruik van TLS offloading zijn er minder afhankelijkheden van certificaten in CPA’s. Daardoor kan de geldigheid van een CPA langer zijn dan de geldigheid van het certificaat.    Voorbeeld van hoe certificaat gegevens doorgegeven kunnen worden.     
72 Bijlage 4   Verplaats naar Digikoppeling Identificatie en Authenticatie     
73 1.2/4 Achtergrond Een belangrijk aspect voor beveiliging van Digikoppeling is de juiste identificatie, authenticatie en autorisatie van organisaties. Digikoppeling maakt hiervoor gebruik van een PKI-infrastructuur met certificaten. Voor Digikoppeling is daarbij gekozen om certificaten toe te passen die voldoen aan de eisen van PKIoverheid. Achtergrond Een belangrijk aspect voor beveiliging van Digikoppeling is de juiste identificatie, authenticatie en autorisatie van organisaties. Voor Digikoppeling is daarbij gekozen om certificaten toe te passen die voldoen aan de eisen van PKIoverheid.    

Digikoppeling Beheermodel v1.4.docx

# Locatie Oorspronkelijke tekst Gewijzigd in # RfC Toelichting
74   Geen inhoudelijke uitleg beveiliging/security/TLS/SHA/PKI/ referenties ‘Digikoppeling Beveiligingsstandaarden en voorschriften' en plaat met documenten aanpassen

Digikoppeling beveiligingsstandaarden en voorschriften v1.docx
 
Dit is een nieuw document met de verplichte Digikoppeling beveiligingsstandaarden en voorschriften, dat onderdeel wordt van de standaard. Zie bovenstaande wijzigingen voor RFCs  1, 4 en 5.