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). |
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 n.a.v. 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
Push request
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 |
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:
|
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:
|
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 Reliable Messaging End-to-End Security |
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 Reliable Messaging Condition for usage of msghSignalsOnly mode is:
End-to-End Security |
||
| 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 Reliable Messaging End-to-End Security |
||
| 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 |
wsa:To |
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 |
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: |
- |
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:
- Gebruik van aanduiding ebMS2 i.p.v. ebMS
- Gebruik van aanduiding CPA Register i.p.v. CPA Creatieregister
- Update figuur structuur Digikoppeling documentatie
- Toevoegen overzicht documentatie
- 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: |
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) |
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 in verband met 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). |
|
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.