Digikoppeling Koppelvlakstandaard ebMS2 3.3.2

Logius Standaard
Vastgestelde versie

Deze versie:
https://gitdocumentatie.logius.nl/publicatie/dk/ebms/3.3.2/
Laatst gepubliceerde versie:
https://gitdocumentatie.logius.nl/publicatie/dk/ebms/
Laatste werkversie:
https://logius-standaarden.github.io/Digikoppeling-Koppelvlakstandaard-ebMS2/
Vorige versie:
https://gitdocumentatie.logius.nl/publicatie/dk/ebms/3.3.1/
Redacteur:
Logius (Logius)
Auteur:
Logius
Doe mee:
GitHub Logius-standaarden/Digikoppeling-Koppelvlakstandaard-ebMS2
Dien een melding in
Revisiehistorie
Pull requests

Dit document is ook beschikbaar in dit niet-normatieve formaat: pdf


Samenvatting

Het document is bestemd voor architecten en ontwikkelaars die op basis van ebMS gegeven willen uitwisselen via Digikoppeling. Zie onderstaande tabel bij welke taken dit document ondersteunt. Alle Digikoppeling webservices die op ebMS gebaseerd zijn, moeten conformeren aan de koppelvlakstandaard ebMS2. Deze wordt tot in detail in dit document gespecificeerd. Het doel van dit document is ontwikkelaars te informeren wat deze koppelvlakstandaard nu precies inhoudt en waar zij zich aan moeten conformeren. Het gaat hierbij om zowel service aanbieders als service afnemers.

Status van dit document

Dit is de definitieve versie van dit document. Wijzigingen naar aanleiding van consultaties zijn doorgevoerd.

Documentbeheer

Datum Versie Auteur Opmerkingen
22-11-2011 2.4 Logius -
09-06-2014 2.5 Logius Redactionele wijzigingen
28-01-2015 3.0 Logius TLS 1.0 t/m TLS 1.2
04-04-2016 3.1 Logius Referenties naar Beveiligingsvoorschriften aangepast naar nieuwe Document Digikoppeling beveiligingsvoorschrift
Requirement Item 4.1.8 (‘Z’ identifier) verwijderd
01-10-2017 3.2 Logius Restrictie 1st payload aangepast
16-05-2019 3.3 Logius Gebruik van SyncReplyMode verruimd
11-04-2022 3.3.1 Logius Vermelding REST-API koppelvlak
31-05-2024 3.3.2 Logius Herstel tabel onder 2.3 Ondersteunde varianten

Colofon

Logius Servicecentrum: Postbus 96810
2509 JE Den Haag
tel. 0900 555 4555 (10 ct p/m)
email servicecentrum@logius.nl

1. Inleiding

1.1 Doel en doelgroep

Dit document beschrijft de functionele specificaties voor Digikoppeling ebMS Deployment Profile, onderdeel van Digikoppeling.

Het document is bestemd voor architecten en ontwikkelaars die op basis van ebMS gegeven willen uitwisselen via Digikoppeling. Zie onderstaande tabel bij welke taken dit document ondersteunt. Alle Digikoppeling webservices die op ebMS gebaseerd zijn, moeten conformeren aan de koppelvlakstandaard ebMS2. Deze wordt tot in detail in dit document gespecificeerd. Het doel van dit document is ontwikkelaars te informeren wat deze koppelvlakstandaard nu precies inhoudt en waar zij zich aan moeten conformeren. Het gaat hierbij om zowel service aanbieders als service afnemers.

Afkorting Rol Taak Doelgroep?
[MT] Management Bevoegdheid om namens organisatie (strategische) besluiten te nemen. Nee
[PL] Projectleiding Verzorgen van de aansturing van projecten. Nee
[A&D] Analyseren & ontwerpen (design) Analyseren en ontwerpen van oplossings-richtingen. Het verbinden van Business aan de IT. Ja
[OT&B] Ontwikkelen, testen en beheer Ontwikkelt, bouwt en configureert de techniek conform specificaties. Zorgen voor beheer na ingebruikname. Ja

1.2 Opbouw Digikoppeling documentatie

Digikoppeling is beschreven in een set van documenten. Deze set is als volgt opgebouwd:

Overzicht van de onderdelen van de Digikoppeling Standaard, de standaard is onderverdeeld in normatieve en ondersteunende onderdelen
Figuur 1 Opbouw documentatie Digikoppeling

Tekstalternatief

* Normatief document

† Ondersteunend document

1.3 Doel en scope van Digikoppeling

Digikoppeling biedt de mogelijkheid om op een sterk gestandaardiseerde wijze berichten uit te wisselen tussen service aanbieders en service afnemers. De uitwisseling tussen partijen wordt in drie lagen opgedeeld:

Digikoppeling richt zich dus uitsluitend op de logistieke laag. Deze afspraken komen in de koppelvlakstandaards en andere voorzieningen.

1.3.1 Leidende principes

De koppelvlakstandaarden dienen te leiden tot een maximum aan interoperabiliteit met een minimum aan benodigde ontwikkelinspanning.

Daarom wordt gekozen voor bewezen interoperabele internationale standaarden.

Digikoppeling maakt berichtenuitwisseling mogelijk op basis van de REST API, ebXML/ebMS en WUS-families van standaarden inclusief de daarbij behorende verwante standaarden.

Aan te sluiten overheidsorganisaties hebben aangegeven op een uniforme manier (één stekker) te willen aansluiten aan Digikoppeling. Organisaties die beschikken over eigen middleware (ESB, broker) kunnen de aansluiting aan Digikoppeling, de adapters, in het algemeen realiseren via voorzieningen in die middleware.

De architectuur is beschreven in het document Digikoppeling Architectuur.

1.4 Koppelvlak & koppelvlakstandaard

Een koppelvlak is een interface die volgens standaarden de gegevensuitwisseling verzorgt. Het werken met vaste standaarden is essentieel voor een koppelvlak. Hierdoor wordt implementatie vergemakkelijkt. Ook wordt het mogelijk diverse soorten berichten door te sturen met een grote mate van interoperabiliteit, omdat via de standaard afspraken over hun inhoud gemaakt is.

Een van de belangrijkste eisen die door de overheid gesteld worden bij de inrichting van generieke voorzieningen is dat er niet veel maatwerk ontwikkeld hoeft te worden, maar dat er van “off the shelf” commercieel of Open Source geleverde software gebruik gemaakt kan worden. Voor Digikoppeling, dus voor de logistieke laag, betreft dat het niet willen ontwikkelen van software voor de adapters.

Dit doel kan bereikt (benaderd) worden doordat gekozen wordt voor internationale (de jure of de facto) vastgelegde standaarden, die door “alle” leveranciers interoperabel zijn geïmplementeerd. Een andere eis is dat met name afnemers gebruik kunnen maken van één “stekker” (één logistiek koppelpunt).

1.4.1 Specificatie van de koppelvlakstandaard

De koppelvlakstandaard beschrijft de eisen waar de adapters aan moeten voldoen om interoperabel met elkaar te kunnen communiceren. Digikoppeling gaat over logistiek, dus over de envelop en niet over de inhoud. De hele set info die tezamen nodig is voor een complete generieke Digikoppeling koppelvlakdefinitie (Raamwerk Specificatie genoemd) bestaat uit:

  • interfacedefinitie “on the wire”, (voorbeeld)listing van SOAP headers, en informatie over velden en hun specifieke inhoud.

1.5 Opbouw van dit document

Hoofdstuk 1 bevat een aantal algemene inleidende onderwerpen.

Hoofdstuk 2 bevat de kern van de standaard met achtergrond en gebruik van de ebMS Deployment Profile.

Hoofdstukken 3 tot en met 5 beschrijven de parameters van het ebMS2 profiel zoals dat gekozen is voor Digikoppeling.

Begrippen en afkortingen worden toegelicht in het document [Digikoppeling Architectuur]. Deze zit in de Digikoppeling standaarddocumentatie.

Dit document en andere documentatie is beschikbaar op www.logius.nl/digikoppeling

2. Koppelvlakstandaard ebMS2

2.1 Inleiding

Dit document specificeert de Koppelvlakstandaard ebMS2 voor berichtenuitwisseling over Digikoppeling (voorheen OverheidsServiceBus) als een toepassing van de EBXML-MSG standaard, de ebXML Message Service Specification versie 2.0 [EBXML-MSG]. Digikoppeling is bedoeld als generieke infrastructuur voor een grote variëteit aan diensten. Deze Standaard is daardoor eveneens generiek en dient nader gespecialiseerd te worden voor specifieke berichtstromen en diensten.

EbXML Messaging [EBXML-MSG] is bedoeld voor verschillende toepassingen en faciliteert die diversiteit door een scala aan configureerbare features en opties te bieden. Elk gebruik van ebXML Messaging in een bepaalde keten of binnen een bepaalde gemeenschap vereist in de praktijk een bepaalde mate van aanvullende standaardisatie. Aangezien veel van de configuratiefeatures in de standaard optioneel zijn, moet precies gedocumenteerd worden welke onderdelen ervan op welke manier toegepast zijn, om op de verschillende relevante niveaus interoperabiliteit te realiseren. Die informatie is hier verzameld en gepubliceerd als configuratiegids voor de gebruikers van Digikoppeling. Het legt de overeengekomen conventies vast voor het gebruik van ebXML message service handlers, de functionaliteit die van een implementatie verwacht wordt en de details voor het gebruik van de standaard.

Een deployment specificatie is niet hetzelfde als een ebXML samenwerkingsprotocol overeenkomst (ook wel aangeduid met een “Collaboration Protocol Profile and Agreement) [ISO 15000-1]. Wel hebben sommige onderdelen van een deployment specificatie gevolgen voor de specifieke invulling van CPA-elementen.

2.2 Terminologie in dit document

Dit document biedt organisaties die gebruik gaan maken van Digikoppeling de basis voor de configuratie van de ebXML Messaging software. Een correcte configuratie is van belang voor het uitwisselen van berichten. Mocht er voor een bepaald onderdeel geen specifieke richtlijn gegeven zijn, dan wordt dit aangegeven met één van de volgende waardes:

2.3 Ondersteunde varianten

De ebXML Messaging 2.0-standaard is de basis van deze specificatie. Deze standaard biedt een hogere mate van configureerbaarheid dan in Digikoppeling-praktijk wenselijk is. Om redenen van interoperabiliteit, eenvoud en overzichtelijkheid onderscheidt deze koppelvlakstandaard een drietal varianten van uitwisselingen. Elke variant veronderstelt bepaalde voorgedefinieerde keuzen voor parameters als synchroniciteit, beveiliging en betrouwbaarheid en is daarmee een “profiel” voor ebXML Messaging.

Elke uitwisseling op basis van het ebXML Messaging versie 2.0 protocol over Digikoppeling zal moeten voldoen aan één van de volgende Digikoppeling ebMS2 profielen:

*: In bepaalde gevallen mag een acknowledgement synchroon verstuurd worden. Zie par 4.4

Voor alle profielen gelden de volgende eigenschappen:

De onderstaande tabel geeft in essentie de eigenschappen van de verschillende Digikoppeling profielen weer. Ten behoeve van het CPA register is de kolom 'CPA Creation' toegevoegd. Voor alle profielen wordt twee-zijdig TLS gebruikt op transport niveau (HTTPS).

Profile Names Transport characteristics
Digikoppeling ebMS2 CPA Creation 2-zijdig TLS Reliable Signed Encrypted Attachments
Best Effort osb-be N/A Optional
Reliable Messaging osb-rm Optional
Best Effort – Signed1 osb-be-s N/A Optional
Reliable – Signed1 osb-rm-s Optional
Best Effort – Encrypted1 osb-be-e N/A Optional
Reliable – Encrypted1 osb-rm-e Optional

N/A = Not applicable
1 End-to-End Security

Met betrekking tot CPA-creatie: zie 6.1 Deployment and Processing requirements for CPAs.

2.4 Berichtuitwisselpatronen

Deze specificatie ondersteunt zowel One Way als Two Way bericht-uitwisselpatronen (message exchange patterns, terminologie ontleend aan [ebMS3]). One Way uitwisselingen ondersteunen bedrijfstransacties voor informatie­verspreiding en notificaties, die geen antwoordbericht veronderstellen. Two Way uitwisselingen ondersteunen bedrijfstransacties van het type Vraag-Antwoord, Verzoek-Bevestig, Verzoek-Antwoord en Handelstransacties (zie [UMMR10], [UMMUG] voor informatie over het concept bedrijfstransactie patronen). In het geval van tweewegsverkeer leggen de ebXML headervelden (MessageId, RefToMessagId en ConversationId) de relatie tussen request berichten en de corresponderende response berichten vast.

Deze specificatie gebruikt uitsluitend een Push binding aan het HTTPS protocol. Dat wil zeggen dat het retourbericht in een tweewegscommunicatie via een afzonderlijke HTTPS connectie verloopt, die is geïnitieerd vanuit de verzender (=de beantwoorder). Het initiële bericht is dan verzonden in een eerdere HTTPS connectie, die afgesloten is na succesvolle overdracht van het heengaande bericht.

De keuze van het te gebruiken profiel is onafhankelijk van het uitwisselpatroon. Het heengaande bericht en (in een tweewegsuitwisseling) het teruggaande bericht kunnen naar keuze gebruik maken van het Best Effort profiel of het Reliable Messaging profiel.

2.5 Beveiligingsaspecten

Deze specificatie maakt gebruik een aantal standaarden op het gebied van beveiliging en voldoet op het moment van schrijven aan geldende richtlijnen en best practices. Aangezien in de loop der tijd kwetsbaarheden kunnen worden ontdekt in de cryptografische algoritmen waarop deze standaarden zijn gebaseerd, is het van belang dat deze specificatie regelmatig op geldigheid hiervan wordt bezien. De specifieke toegepaste referenties zijn beschreven in Digikoppeling Beveiligingsstandaarden en voorschriften.

2.6 Format van dit document

Het OASIS Implementation, Interoperability en Conformance (IIC) Technical Committee (TC) heeft voor deployment specificaties een sjabloon opgesteld [Deployment Guide 1.1]. Dat sjabloon is al eerder toegepast door bepaalde sectoren zoals handel (GS1) en gezondheidszorg (HL7), en wordt daarmee een standaard manier van het beschrijven van configuraties. Dit document is opgesteld aan de hand van dat sjabloon. Het is slechts een summiere beschrijving van het specifieke gebruik van ebXML Messaging en bevat geen achtergrondinformatie, motivatie, voorbeelden en andere informatie die nuttig is voor het in de praktijk toepassen van deze specificatie.

Dit document is direct afgeleid van [Deployment Guide 1.1] en om praktische redenen (grotendeels) in het Engels opgesteld. Leveranciers van producten en diensten rond ebXML Messaging zijn bekend met dit sjabloon doordat het ook in andere sectoren wordt gebruikt. Leveranciers kunnen aan de hand van dit sjabloon eenvoudig nagaan in hoeverre hun product voldoet aan de gestelde eisen.

Dit document is niet (geheel) zelfstandig te lezen maar bedoeld om geraadpleegd te worden samen met de technische specificatie [EBXML-MSG].

3. Profiling the Modules of ebMS 2.0

3.1 Core Modules

3.1.1 Core Extension Elements [ebMS 2.0] Section 3

Profile(s) Usage: required/optional/never used in this profile
Best effort
Reliable Messaging
End-to-End Security
Support is required.

3.1.2 Security Module [ebMS 2.0] Section 4.1

Profile(s) Usage: required/optional/never used in this profile
Best effort,
Reliable Messaging,
End-to-End Security
The Security Module is required in this profile.
Security profile 3 [EBXML-MSG]/Appendix C must be used: “Sending MSH authenticates and both MSH's negotiate a secure channel to transmit data”. The HTTPS connection uses encryption to provide in transit confidentiality of the complete ebXML message and performs both certificate-based Client and Server authentication during the TLS handshake.
End-to-End Security Security profile 8 [EBXML-MSG]/Appendix C must be used: “Sending MSH applies XML/DSIG structures to message and passes in secure communications channel. Sending MSH applies XML/DSIG structures to message and Receiving MSH returns a signed receipt.”

3.1.3 SyncReply Module [ebMS 2.0] Section 4.3

Profile(s) Usage: required/optional/never used in this profile Notes
Best effort Never used in this profile (empty)
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. 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
End-to-End Security Optional used in this profile. See profile Best Effort or profile Reliable Messaging for details (empty)

3.2 Additional Modules

3.2.1 Reliable Messaging Module [ebMS 2.0] Section 6

Profile(s) Usage: required/optional/never used in this profile Notes
Best effort Never used in this profile. The ebXML reliable messaging protocol is not used. Acknowledgment Messages must not be sent or requested, and the receiver should not eliminate duplicate messages.
Reliable Messaging Required in this profile. Reliable Messaging profile 2, Once-And-Only-Once Reliable Messaging at the End-To-End level only based upon end-to-end retransmission. In this profile the FromParty MSH (message origination) must request, and the ToParty MSH (message final destination) must send an acknowledgment message. The ToParty MSH must also filter any duplicate messages based on ebXML MessageId. Any intermediate NextMSH ebXML-aware nodes (see caveat in section 'Multi-Hop Module' in this chapter) have no reliable messaging functionality. Acknowledgment messages must not be consumed by any such intermediary but routed like any ebXML Message back to the original (true) sender.
End-to-End Security Optional used in this profile. See profile Best Effort or profile Reliable Messaging for details. (empty)

3.2.2 Message Status Service [ebMS 2.0] Section 7

Profile(s) Usage: required/optional/never used in this profile Notes
Best effort,
Reliable Messaging,
End-to-End Security
Optional. Message Status Service is not required in these profiles. (empty)

3.2.3 Ping Service [ebMS 2.0] Section 8

Profile(s) Usage: required/optional/never used in this profile Notes
Best effort,
Reliable Messaging,
End-to-End Security
Ping Service is not required in these profiles. (empty)

3.2.4 Message Order [ebMS 2.0] Section 9

Profile(s) Usage: required/optional/never used in this profile Notes
Best effort,
Reliable Messaging,
End-to-End Security
Optional. Message Order is strongly discouraged in these profiles. Many organisations use message handlers that do not support this functionality. Therefore, it can only be used if communicating parties agree to this option in advance. This specification is limited to message service handler order functionality and does not preclude application-level in-order processing if sequence information is somehow provided at the business document level.

3.2.5 Multi-Hop Module [ebMS 2.0] Section 10

Profile(s) Usage: required/optional/never used in this profile Notes
Best effort,
Reliable Messaging,
End-to-End Security
Never used in this profile. Multi-hop is the process of passing the message through one or more intermediary nodes or MSH's. An Intermediary is any node or MSH where the message is received, but is not the Sending or Receiving MSH endpoint. This node is called an Intermediary.

4. Communication Protocol Bindings

4.1 Profile Requirement Item: Transport Protocol

[EBXML-MSG] Appendix B Best effort,
Reliable Messaging,
End-to-End Security
Is HTTP a required or allowed transfer protocol? (See section B.2 for specifics of this protocol.) Never used in this profile. HTTPS is used instead.
Is HTTP a required or allowed transfer protocol? (See section B.2 for specifics of this protocol. HTTPS is the required transport protocol.
Is (E)SMTP a required or allowed transfer protocol? (See section B.3 for specifics of this protocol.) (E)SMTP is never used in this profile.
If SMTP, What is needed in addition to the ebMS minimum requirements for SMTP? Not applicable
Are any transfer protocols other than HTTP and SMTP allowed or required? If so, describe the protocol binding to be used.** No other protocols are supported.
Alignment (empty)
Test References (empty)
Notes (empty)

5. Profile Requirements Details

5.1 Module: Core Extension Elements

5.1.1 Profile Requirement Item: PartyId

[EBXML-MSG] Section 3.1.1.1 All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
PartyId Element Header elements:
SOAP:Header/eb:MessageHeader/eb:From/eb:PartyId
SOAP:Header/eb:MessageHeader/eb:To/eb:PartyId
Is a specific standard used for party identification? Provide details. Example - EAN•UCC Global Location Number. Ref.: ISO6523 - ICD0088. Partners who are going to use ebMS for the first time must use an OIN (Organisatie Identificatie Nummer) for identification. Partners who are already using ebMS and are using other identification schemes are allowed to use their identification: the type attribute must identify their identification scheme and must be different from urn:osb:oin. The use of their own identification should be temporary: the partner should start using OIN at a certain moment for identification using Digikoppeling. For non-production environments a suffix is allowed after the OIN to distinguish it from production (e.g. “_OTA” or “_T”)

OIN stands for Organisatie Identificatie Nummer and is maintained by Logius in the COR (Centrale OIN Raadpleegvoorziening). The number is unique and allows identification of partners, even if they are not themselves legal entities, but departments or units of larger organizations.

The OIN used for PartyId must be the same as the OIN from the end-party and should not contain the OIN from an intermediate party. In case the end-party is the same party that performs TLS, signing and/or encryption the OIN used for PartyId should be identical to the OIN used for the TLS-, signing- and/or encryption-certificate respectively. Hence, if the end-party does not perform TLS, signing and/or encryption the corresponding OIN’s may differ.
Should multiple PartyId elements be present in From and To elements? (empty)
Is the type attribute needed for each PartyId, and if so, what must it contain? Example – within the EAN•UCC system, the PartyId element and type are represented using Global Location Number.<eb:PartyId eb:type="http:/www.iso.int/schemas/eanucc/gln"/>1234567890128</eb:PartyId> The type attribute must be present and should have the fixed value.
The following type attribute value has to be used in case of an OIN is used by the partner: urn:osb:oin
alignment appears as PartyId element in CPA. (c)
appears as PartyId/@type in CPA
Test References (empty)
notes ISO 6523 is an international standard registry of agencies issuing codes. Value 0106 in this registry identifies the Association of Chambers of Commerce and Industry in the Netherlands. The prefix urn:oasis:names:tc:ebxml-cppa:PartyId-type is used to indicate the issuing agency is an ISO 6523 registered agency. The type attribute allows unique identification of the agency that issues the number or code that identifies the partner. In theory, this mechanism allows multiple identification systems to be used in parallel, with no requirement that the codes in those systems do not overlap.

5.1.2 Profile Requirement Item: Role

[EBXML-MSG] Section 3.1.1.2 Role Element All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements /SOAP:Header/eb:MessageHeader/eb:From/eb:Role
/SOAP:Header/eb:MessageHeader/eb:To/eb:Role
Are Roles defined for each party of each business process? List them, or provide a reference to the source of these values. Example – within the EAN•UCC system, approved values are specified by the EAN•UCC Message Service Implementation Guide. Business process is out of scope for (this version of the) Digikoppeling. Within a single contract (CPA) between two Partners: - A Partner must fulfill one and only one role (a Partner cannot change its role within one contract). - A Partner can send messages (one or more) and/or receive messages (one or more). In case a Partner wants to use different roles, different contracts (CPA's) must be used.
Alignment [Per-process; may reference Role values in BPSS [BPSS] definitions. Appears as Role/@name in CPA.]
Test References (empty)
Notes (empty)

5.1.3 Profile Requirement Item: CPAId

[EBXML-MSG] Section 3.1.2 CPAId Element All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header element(s) /SOAP:Header/eb:MessageHeader/eb:CPAId
What identification scheme is used for the CPAId, and what form should it take? If it is a URI, how is it constructed? Does it reference a real CPA, or is it just a symbolic identifier? Example – within the EAN•UCC system, the value of the CPAId is the concatenation of the Sender and Receiver GLNs followed by a four digit serial number. 1234567890128 - GLN Party A 3456789012340 - GLN Party B 0001 - CPA Number between parties A and B The proposed EAN•UCC is recommended as a good practice.
Alignment Appears as CollaborationProtocolAgreement/@cpaid in CPA.
Test References (empty)
Notes (empty)

5.1.4 Profile Requirement Item: ConversationId

[EBXML-MSG] Section 3.1.3 ConversationId Element All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements /SOAP:Header/eb:MessageHeader/eb:ConversationId
What is the user definition of a Conversation? What is the business criterion used to correlate messages considered parts of the same conversation? [EBXML-MSG] requires that request messages, response messages, and any acknowledgments and error messages have the same value for ConversationId.
In case the MSH implementation gives exposure of the ConversationId as it appears in the header, what identification scheme should be used for its value, and what format should it have? If it is a URI, how is it constructed? In case the ConversationId is not directly exposed, but only a handle that allows applications to associate messages to conversations, if the value of this handle is under control of the application, what format should it have? No recommendation made.
If BPSS is used, ConversationId typically maps to a business transaction. Is that the case? Does it map to a business collaboration instead? No recommendation made. Business process is out of scope for Digikoppeling.
Test References (empty)
Notes ConversationId is a required ebXML message header element.

5.1.5 Profile Requirement Item: MessageId

[EBXML-MSG] Section 3.1.6.1 All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements /SOAP:Header/eb:MessageHeader/eb:MessageData/eb:MessageId
Although there is no requirement for an MSH to give control about MessageId to an application, some implementations may allow this. In this case, is there any requirement on the source of this ID? Any length and format restrictions when the ID is generated? No recommendation made. The value of MessageId does not need to meet any requirements beyond the string format specified in [EBXML-MSG] and the global uniqueness constraint of [rfc5322].
Alignment (empty)
Test References (empty)
Notes (empty)

5.1.6 Profile Requirement Item: Service

[EBXML-MSG] Section 3.1.4 Service Element All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements /SOAP:Header/eb:MessageHeader/eb:Service
/SOAP:Header/eb:MessageHeader/eb:Service/\@type
Are Services (related groups of Actions) defined for each party of each business process? List them, or provide a reference to the source of these values. [Per-process; absent from BPSS definitions.] Is there a URI format scheme for this element? No recommendation made.
Is there a defined "type" for Service elements? If so, what value must the type attribute contain? The text content of the Service element must not contain white space.
Alignment Appears as Service element in CPA Appears as Service/@type in CPA
Test References (empty)
Notes (empty)

5.1.7 Profile Requirement Item: Action

[EBXML-MSG] Section 3.1.5 Action Element All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements /SOAP:Header/eb:MessageHeader/eb:Action
Are actions defined for each party to each business process? List them, or provide a reference to the source of these values. [Per-process; may reference BusinessAction values in BPSS definitions. Example – within the EAN•UCC system, approved values are specified by the EAN•UCC Message Service Implementation Guide. <eb:Action>Confirmation</eb:Action> No recommendation made.
Alignment Appears as ThisPartyActionBinding/@action in CPA.]
Test References (empty)
Notes The text content of the Action element in the header must not contain white space.

5.1.8 Profile Requirement Item: Timestamp (removed)

This item is no longer required.

5.1.9 Profile Requirement Item: Description

[EBXML-MSG] Section 3.1.8 Description Element All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements /SOAP:Header/eb:MessageHeader/eb:Description
Are one or more Message Header Description elements required? In what language(s)? Is there a convention for its contents? No recommendation made. Description elements are not required. Message handlers may ignore Description elements.
Alignment (empty)
Test References (empty)
Notes (empty)

5.1.10 Profile Requirement Item: Manifest

[EBXML-MSG] Section 3.2.2 Manifest Validation All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements /SOAP:Body/eb:Manifest
How many Manifest elements must be present, and what must they reference? Does the order of Manifest elements have to match the order of the referenced MIME attachments? Any restriction on the range of value for xlink:reference (e.g. nothing other than content id references)? Manifest elements must only reference business documents or other payloads that are included in the ebXML message as a MIME part allows for references to external message payloads (for instance, using HTTP URIs), which are logically part of the message, but not as a physical entity in the MIME envelope. This is never used in these profiles.
Must a URI whichcannot be resolved be reported as an error? A Content Id URI reference that cannot be resolved must be treated as an error.
Alignment (empty)
Test References (empty)
Notes XML or other business documents can have references to other resources that are not part of the ebXML message. It is up to the receiving application to interpret any such references.

5.1.11 Profile Requirement Item: Reference

[EBXML-MSG] Section 3.2.1 Reference Element All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header element(s) /SOAP:Body/eb:Manifest/eb:Reference
Is the xlink:role attribute required? What is its value? Not applicable. The xlink:role attribute is not required.
Are any other namespace-qualified attributes required? Not applicable. No other namespace-qualified attributes are allowed.
Alignment (empty)
Test References (empty)
Notes Only the Content Id reference mechanism [rfc2392] is allowed.

5.1.12 Profile Requirement Item: Reference/Schema

[EBXML-MSG] All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header element(s) /SOAP:Body/eb:Manifest/eb:Reference/eb:Schema
Are there any Schema elements required? If so, what are their location and version attributes? Schema elements are not required. Digikoppeling does not perform XML schema validation.
Alignment (empty)
Test References (empty)
Notes (empty)

5.1.13 Profile Requirement Item: Reference/Description

[EBXML-MSG] Section 3.2.1.2 Description Element All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header element(s) /SOAP:Body/eb:Manifest/eb:Reference/eb:Description
Are any Description elements required? If so, what are their contents? Description elements are optional. They may be ignored by any receiving message service handler.
Alignment (empty)
Test References (empty)
Notes (empty)

5.2 Module: Security

5.2.1 Profile Requirement Item: Signature generation

[EBXML-MSG] Section 4.1.4.1 Persistent Digital Signature Best effort
Reliable Messaging
End-to-End Security
Header elements:
SOAP:Header/Signature
(a) Must messages be digitally signed? [Yes, for Security Services Profiles 1, 6-21.] Not applicable. These profiles do not support XML Digital Signatures at the message handler level. Required in this profile.
Are additional Signature elements required, by whom, and what should they reference? Not applicable. Never used in this profile.
What canonicalization method(s) must be applied to the data to be signed? Not applicable. The use of XML canonicalization is required. [xml-exc-c14n]
What canonicalization method(s) must be applied to each payload object, if different from above? Not applicable. Not applicable.
What signature method(s) must be applied? Not applicable. The applied signature method is described in Digikoppeling Beveiligingsstandaarden en voorschriften
What Certificate Authorities (issuers) are allowed or required for signing certificates? Not applicable. The use of PKI Overheid certificates is required in which an OIN is used in the Subject.serialNumber. Digikoppeling Beveiligingsstandaarden en voorschriften
Are direct-trusted (or self-signed) signing certificates allowed? Not applicable. This profile is never used. Only used in testing and Proof of Concept environments
What certificate verification policies and procedures must be followed? The requirements as stated in Certificate Policy/Programme of Requirements PKIoverheid have to be used. The use of certificate revocation lists (CRL) from the trusted CAs is required. The requirements as stated in Certificate Policy/Programme of Requirements PKIoverheid have to be used. The use of certificate revocation lists (CRL) from the trusted CA's is required.
Alignment (a) Appears as BusinessTransactionCharacteristics/@isAuthenticated=persistent and BusinessTransactionCharacteristics/@isTamperProof=persistent in CPA
Test References (empty) (empty)
Notes Applications submitting data to, or receiving data from, Digikoppeling ebXML Message service handlers can perform signing at the message payload level. The ebXML Messaging protocol is payload-neutral and therefore supports signed payloads. In that case, the Digikoppeling is not aware of the presence of signatures and does not perform signature verification. for more information see Digikoppeling Beveiligingsstandaarden en voorschriften

5.2.2 Profile Requirement Item: Persistent Signed Receipt

[EBXML-MSG] Section 4.1.4.2 Persistent Signed Receipt Best effort
Reliable Messaging
End-to-End Security
Header elements:
/SOAP:Header/eb:Signature
Is a digitally signed Acknowledgment Message required? [Yes, for Security Services Profiles 7, 8, 10, 12, 14, 15, 17, 19-21. See the items beginning with Section 4.1.4.1 for specific Signature requirements.] Not applicable. Signing acknowledgements is required.
If so, what is the Acknowledgment or Receipt schema? Not applicable. [xmldsig-core-20020212]
Alignment Appears as BusinessTransactionCharacteristics/@isNonRepudiationReceiptRequired=persistent in CPA.
Test References (empty) (empty)
Notes (empty) (empty)

5.2.3 Profile Requirement Item: Non Persistent Authentication

[EBXML-MSG]Section 4.1.4.3 Non Persistent Authentication All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Are communication channel authentication methods required? [Yes, for Security Services Profiles 2-5.] Which methods are allowed or required? Client and Server authentication is required using HTTPS and TLS. The currently allowed protocol versions for TLS are described in Digikoppeling Beveiligingsstandaarden en voorschriften Note: Message service handlers should NOT be able to operate in SSL v3 backward compatibility mode.
Alignment [Appears as BusinessTransactionCharacteristics/@isAuthenticated=transient in CPA.]
Test References (empty)
Notes for more information see Digikoppeling Beveiligingsstandaarden en voorschriften

5.2.4 Profile Requirement Item: Non Persistent Integrity

[EBXML-MSG] Section 4.1.4.4 Non Persistent Integrity All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header element(s) /SOAP:Header/eb:Signature
Are communication channel integrity methods required? [Yes, for Security Services Profile 4.] Which methods are allowed or required? Not applicable
Alignment [Appears as BusinessTransactionCharacteristics/@isTamperproof=transient in CPA.]
Test References (empty)
Notes (empty)

5.2.5 Profile Requirement Item: Persistent Confidentiality

[EBXML-MSG] Section 4.1.4.1 Section 4.1.4.5 Persistent Confidentiality Best effort
Reliable Messaging
End-to-End Security
Header elements:
/SOAP:Header/eb:Signature
Is selective confidentiality of elements within an ebXML Message SOAP Header required? If so, how is this to be accomplished? [Not addressed by Messaging Specification 2.0.] Not applicable. Not applicable.
Alignment [Appears as BusinessTransactionCharacteristics/@isConfidential=persistent in CPA.]
Test References (empty) (empty)
Notes Applications submitting data to, or receiving data from, Digikoppeling message handlers can perform encryption at the payload processing level. The ebXML Messaging protocol is payload-neutral and therefore supports transport of encrypted payloads. However, any encryption and decryption of payloads is out of scope for these profiles.

5.2.6 Profile Requirement Item: Non Persistent Confidentiality

[EBXML-MSG] Section 4.1.4.6 Non Persistent Confidentiality All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header element(s) /SOAP:Header/eb:Signature
Are communication channel confidentiality methods required? [Yes, for Security Services Profiles 3, 6, 8, 11, 12.] Which methods are allowed or required? The use of HTTPS and TLS is required. The currently allowed protocol versions for TLS are described in Digikoppeling Beveiligingsstandaarden en voorschriften Message service handlers should NOT support SSL v3 compatibility mode.
Alignment [Appears as BusinessTransactionCharacteristics/@isConfidential=transient in CPA.]
Test References (empty)
Notes For more information see Digikoppeling Beveiligingsstandaarden en voorschriften

5.2.7 Profile Requirement Item: Persistent Authorization

[EBXML-MSG] Section 4.1.4.7 Persistent Authorization All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header element(s) /SOAP:Header/eb:Signature
Are persistent authorization methods required? [Yes, for Security Services Profiles 18-21.] Which methods are allowed or required? Not applicable
Alignment [Appears as BusinessTransactionCharacteristics/@isAuthorizationRequired=persistent in CPA.]
Test References (empty)
Notes (empty)

5.2.8 Profile Requirement Item: Non Persistent Authorization

[EBXML-MSG] Section 4.1.4.8 Non Persistent Authorization All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header element(s) /SOAP:Header/eb:Signature
Are communication channel authorization methods required? [Yes, for Security Services Profile 2.] Which methods are allowed or required? TLS client and server authentication is required as described in section in 4.2.3.
Alignment [Appears as BusinessTransactionCharacteristics/@isAuthorizationRequired=transient in CPA.]
Test References (empty)
Notes (empty)

5.2.9 Profile Requirement Item: Trusted Timestamp

[EBXML-MSG] Section 4.1.4.9 Trusted Timestamp All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header element(s) /SOAP:Header/eb:Signature
Is a trusted timestamp required? [Yes, for Security Services Profiles 9-12, 15-17, 20, 21.] If so, provide details regarding its usage. Not applicable
Alignment (empty)
Test References (empty)
Notes Applications submitting data to, or receiving data from, Digikoppeling message handlers can perform timestamping. The ebXML Messaging protocol is payload-neutral and therefore supports timestamped payloads. However, this timestamping functionality is not part of the Digikoppeling functionality. Any valid ebXML Message must contain an eb:TimeStamp as part of the eb:MessageData.

5.3 Module : Error Handling

5.3.1 Profile Requirement Item

[EBXML-MSG] Section 4.2.3.2 Error Element All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements /SOAP:Header/eb:ErrorList/eb:Error
/SOAP:Header/eb:ErrorList/ eb:Error/\@codeContext
/SOAP:Header/eb:ErrorList/ eb:Error/\@errorCode
Is an alternative codeContext used? If so, specify Not applicable
If an alternative codeContext is used, what is its errorCode list?
Profiling (c) When errors should be reported to the sending application, how should this be notified (e.g. using a logging mechanism or a proactive callback)?
Alignment (empty)
Test References (empty)
Notes (empty)

5.4 Module : SyncReply

5.4.1 Profile Requirement Item: SyncReply

[EBXML-MSG] Section 4.3 SyncReply Best effort Reliable Messaging End-to-End Security
Header elements:
SOAP:Header/eb:SyncReply
Is SyncReply mode allowed, disallowed, or required, and under what circumstances? [May be process-specific.] Not applicable. 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] See profile Best Effort or profile Reliable Messaging for details
If SyncReply mode is used, are MSH signals, business messages or both expected synchronously? Not applicable If SyncReply mode used only MSH signals are expected synchronously See profile Reliable Messaging for details
Alignment [Affects setting of 6.4.7 syncReplyMode element. Appears as MessagingCharacteristics/@syncReplyMode in CPA.]
Test References (empty)
Notes Asynchronous messaging does not preclude support of a “near real time” response quality of service required for e.g. interactive applications. The ebXML MessageId and RefTo MessageId header elements encode correlation of request and response messages.

5.5 Module : Reliable Messaging

5.5.1 Profile Requirement Item: SOAP Actor attribute

[EBXML-MSG] Section 6.3.1.1 SOAP Actor attribute Best effort Reliable Messaging End-to-End Security
Header elements:
/SOAP:Header/eb:AckRequested/
SOAP Actor attribute: Are point-to-point (nextMSH) MSH Acknowledgments to be requested? [Yes, for RM Combinations 1, 3, 5, 7; refer to ebMS section 6.6. Appears as MessagingCharacteristics/@ackRequested with @actor=nextMSH in CPA.] Not applicable. Not applicable Not applicable
Are end-to-end (toParty) MSH Acknowledgments to be requested? [Yes, for RM Combinations 1, 2, 5, 6. Appears as MessagingCharacteristics/@ackRequested with @actor=toPartyMSH in CPA.] Not applicable. It is required that the final recipient MSH returns a receipt acknowledgment message. Optional: See profiles Best Effort or Reliable Messaging for details.
Test References (empty)
Notes (empty)

5.5.2 Profile Requirement Item: Signed attribute

[EBXML-MSG] Section 6.3.1.2 Signed attribute All profiles:
Best effort
Reliable Messaging
End-to-End Security
Header elements:
/SOAP:Header/eb:AckRequested/
Must MSH Acknowledgments be (requested to be) signed? Not applicable. Not applicable.
Alignment [Appears as MessagingCharacteristics/ @ackSignatureRequested in CPA.]
Test References (empty)
Notes (empty)

5.5.3 Profile Requirement Item: DuplicateElimination

[EBXML-MSG] Section 6.4.1 Best effort Reliable Messaging End-to-End Security
Header elements:
/SOAP:Header/eb:AckRequested/
Is elimination of duplicate messages required? [Yes, for RM Combinations 1-4.] Duplicate Elimination is never used. Duplicate Elimination is required Duplicate Elimination is optional. See profiles Best Effort or Reliable Messaging for details.
What is the expected scope in time of duplicate elimination? In other words, how long should messages or message ID's be kept in persistent storage for this purpose? (empty) Message ID's should minimally be kept in persistent storage to prevent duplicate delivery during the time interval in which the From Party MSH may be attempting to resend unacknowledged messages. The minimum is (1+Retries)*RetryInterval. (empty)
Alignment Appears as MessagingCharacteristics/ @duplicateElimination in CPA
Test References (empty)
Notes Message ID's in ebXML are based on [rfc5322], and must therefore be globally unique, which in theory prevents accidental re-use of ID's for distinct messages. Factors like system load, disk space, database table limitations, period maintenance schedules may be used in message purging policies. Cleaning message ID stores often (temporarily) affects responsiveness of a system.

5.5.4 Profile Requirement Item: Retries and RetryInterval

[EBXML-MSG]Section 6.4.3, 6.4.4 Retries and RetryInterval Best effort Reliable Messaging End-to-End Security
Header elements:
/SOAP:Header/eb:AckRequested/
(a) If reliable messaging is used, how many times must an MSH attempt to redeliver an unacknowledged message?
(b) What is the minimum time a Sending MSH should wait between retries of an unacknowledged message?
Not applicable Some organizations using the Digikoppeling may not have 24x7 support for their ebXML Messaging services. A system crash may not be remedied until the next working day. Where possible, the values of Retries and RetryInterval should be set to allow reliable delivery of messages even after prolonged unavailability. If no value is defined by the parties, a value of 5 days is used. Depends on the use of best effort or reliable messaging.
Alignment (a) [Appears as ReliableMessaging/Retries in CPA.] (b) [Appears as ReliableMessaging/RetryInterval in CPA.]
Test References (empty)
Notes If reliable messaging is used: Some ebXML messaging software products have a transport retry mechanism, in addition to the ebXML retry mechanism. In this case the ebXML retry interval should be set in such a way that any such transport retries have been completed first.

5.5.5 Profile Requirement Item: PersistDuration

[EBXML-MSG]Section 6.4.6 PersistDuration Best effort Reliable Messaging End-to-End Security
How long must data from a reliably sent message be kept in persistent storage by a receiving MSH, for the purpose of retransmission? Not applicable Depends on the retry interval as defined in the particular collaboration, defined by the involved parties. If no value is defined by the parties, a value of 5 days is used. Depends on the use of best effort or reliable messaging.
Alignment [Appears as ReliableMessaging/PersistDuration in CPA.]
Test References (empty)
Notes (empty)

5.5.6 Profile Requirement Item: Reliability Protocol

[EBXML-MSG]Section 6.5.3, 6.5.7 Best effort Reliable Messaging End-to-End Security
Usage: required/optional/never used in this profile, Profiled: yes / no Never used in this profile. The Reliable Messaging Protocol in [EBXML-MSG] must be used. Optional in this profile: depends on the use of best effort or reliable messaging.
Must a response to a received message be included with the acknowledgment of the received message? Are they to be separate, or are both forms allowed? Not applicable Receipt acknowledgment messages are standalone messages. They must not to be bundled with business response messages or other ebXML messages.
If a DeliveryFailure error message cannot be delivered successfully, how must the error message's destination party be informed of the problem? Each collaborating party is responsible for defining procedures for handling these issues.
Alignment (empty)
Test References (empty)
Notes (empty)

5.6 Module : Message Status

5.6.1 Profile Requirement Item: Status Request message

[EBXML-MSG] Section 7.1.1 Message Status Request All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header element(s) Eb:MessageHeader/eb:StatusRequest
If used, must Message Status Request Messages be digitally signed? Not applicable.
Must unauthorized Message Status Request messages be ignored, rather than responded to, due to security concerns? Not applicable.
Alignment (empty)
Test References (empty)
Notes (empty)

5.6.2 Profile Requirement Item: Status Response message

[EBXML-MSG] Section 7.1.2 Message Status Response All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header element(s) Eb:MessageHeader/eb:StatusResponse
If used, must Message Status Response Messages be digitally signed? Not applicable.
Alignment (empty)
Test References (empty)
Notes (empty)

5.7 Module : Ping Service

5.7.1 Profile Requirement Item: Ping-Pong Security

[EBXML-MSG] Section 8.1, 8.2 Message Service Handler Ping/Pong Message All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header element(s) Eb:MessageHeader/eb:Service
If used, must Ping Messages be digitally signed? If Ping-Pong is used, it is optional for Ping messages to be digitally signed.
If used, must Pong Messages be digitally signed? If Ping-Pong is used, it is optional for Pong messages to be digitally signed.
Under what circumstances must a Pong Message not be sent? No recommendation made.
If not supported or unauthorized, must the MSH receiving a Ping respond with an error message, or ignore it due to security concerns? No recommendation made
Alignment (empty)
Test References (empty)
Notes (empty)

5.8 Module : Multi-Hop

5.8.1 Profile Requirement Item: Use of intermediaries

[EBXML-MSG] Section 10 All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements
Are any store-and-forward intermediary MSH nodes present on the message path? Endpoints connecting to the Digikoppeling must be able to operate in Endpoint mode. They attempt to deliver inbound messages locally, and may treat any exceptions as failures. They are not required to support any forwarding of ebXML Messages to other business partners.
What are the values of Retry and RetryInterval between intermediate MSH nodes? Not applicable. Any Digikoppeling-level intermediaries must not support reliable messaging, in order to not interfere with end-to-end reliable message delivery. Message handlers must not request nextMSH receipt acknowledgments and such requests should be ignored by any ebXML intermediary. The ebXML intermediaries also should not filter duplicate messages. As with business messages, any Digikoppeling-level ebXML intermediaries should attempt to forward end-to-end receipts and errors.
Alignment (empty)
Test References (empty)
Notes In case Best Effort is used: Any Digikoppeling-level ebXML intermediary may support transport retries, for instance to handle temporary TCP or HTTP transport level errors. This is not required. 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. In case End-to-End Security is used: see the notes for Best effort of Reliable messaging.

5.8.2 Profile Requirement Item: Acknowledgements

[EBXML-MSG] Section 10.1.1, 10.1.3 All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header element(s) Eb:MessageHeader/
Must each intermediary request acknowledgment from the next MSH? Not applicable. There is no support for ebXML next MSH acknowledgments.
Must each intermediary return an Intermediate Acknowledgment Message synchronously? Not applicable. There is no support for ebXML next MSH acknowledgments.
If both intermediary (multi-hop) and endpoint acknowledgments are requested of the To Party, must they both be sent in the same message? Not applicable. There is no support for ebXML next MSH acknowledgments.
Alignment (empty)
Test References (empty)
Notes (empty)

5.9 SOAP Extensions

5.9.1 Profile Requirement Item: #wildCard, Id

[EBXML-MSG] Section 2.3.6, 2.3.7, 2.3.8 All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
(Section 2.3.6) #wildcard Element Content: Are additional namespace-qualified extension elements required? If so, specify. Not applicable. No additional namespace-qualified extension elements are required. The toPartyMSH and any intermediaries must ignore any extension elements.
(Section 2.3.7) Is a unique “id” attribute required for each (or any) ebXML SOAP extension element, for the purpose of referencing it alone in a digital signature? Not applicable. Digital Signing is not supported.
(Section 2.3.8) Is a version other than "2.0" allowed or required for any extension elements? These profiles are limited to ebXML Messaging version 2.0 [EBXML-MSG].
Alignment (empty)
Test References (empty)
Notes (empty)

5.10 MIME Header Container

5.10.1 Profile Requirement Item: charset

[EBXML-MSG] Section 2.1.3.2 All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
MIME Header elements Content-Type
Is the "charset" parameter of Content-Type header necessary? If so, what is the (sub)set of allowed values? Example: Content-Type: text/xml; charset="UTF-8" UTF-8
Alignment (empty)
Test References (empty)
Notes (empty)

5.11 HTTP Binding

5.11.1 Profile Requirement Item: HTTP Headers

[EBXML-MSG] Appendix B.2.2 Sending ebXML Service messages over HTTP All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements MIME parts
Is a (non-identity) content-transfer-encoding required for any of the MIME multipart entities? Content transfer encoding should not be used.
If other than "ebXML" what must the SOAPAction HTTP header field contain? The value of the SOAPAction HTTP header field MUST be “ebXML”
What additional MIME-like headers must be included among the HTTP headers? Additional MIME-like headers should not be included with the HTTP header. Any ebXML MSH should ignore any such additional HTTP header.
Alignment (empty)
Test References (empty)
Notes (empty)

5.11.2 Profile Requirement Item: HTTP Response Codes

[EBXML-MSG] Appendix B.2.3 HTTP Response Codes All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements MIME parts
What client behaviors should result when 3xx, 4xx or 5xx HTTP error codes are received? In the event of an HTTP 5xx error code, the MSH must behave according to the recommendations specified in [SOAP]. An HTTP 503 error code should be treated as a recoverable error (i.e. should not terminate any reliable messaging retries). Codes in the 3xx and 4xx ranges must be interpreted as errors.
Alignment (empty)
Test References (empty)
Notes (empty)

5.11.3 Profile Requirement Item: HTTP Access Control

[EBXML-MSG] Appendix B.2.6 Access Control Header elements All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements MIME parts
Which HTTP access control mechanism(s) are required or allowed? Basic, Digest, or client certificate (the latter only if transport-layer security is used), for example. Refer to item 4.1.4.8 in Security section. Access control is based on client certificate information only. HTTP Basic or Digest authentication are not supported.
Alignment Appears as AccessAuthentication elements in CPA.
Test References (empty)
Notes (empty)

5.11.4 Profile Requirement Item: HTTP Confidentiality and Security

[EBXML-MSG] Appendix B.2.7 Confidentiality and Transport Protocol Level Security All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements MIME parts
Is HTTP transport-layer encryption required? What protocol version(s)? [SSLv3, TLSv1, for example. Refer to item 4.1.4.6 in Security section.] Encryption is based on HTTPS and TLS. The currently allowed protocol versions for TLS are described in Digikoppeling Beveiligingsstandaarden en voorschriften Note: TLS implementations must NOT support SSL v3 backwards compatiblity mode.
What encryption algorithm(s) and minimum key lengths are required? The currently allowed protocol versions for TLS are described in Digikoppeling Beveiligingsstandaarden en voorschriften
What Certificate Authorities are acceptable for server certificate authentication? PKI overheid maintains a list of approved trusted service providers Aansluiten als Trust Service Provider.
Are direct-trust (self-signed) server certificates allowed? Self-signed certificates are only allowed in test cases.
Is client-side certificate-based authentication allowed or required? Client-side authentication is required.
What client Certificate Authorities are acceptable? PKI overheid maintains a list of approved trusted service providers Aansluiten als Trust Service Provider.
What certificate verification policies and procedures must be followed? PKI overheid procedures are described in Certificate Policy/Programme of Requirements PKIoverheid. The use of certificate revocation lists (CRL) from the trusted CA's is required.
Alignment (empty)
Test References (empty)
Notes For more information see Digikoppeling Beveiligingsstandaarden en voorschriften

5.12 SMTP Binding

5.12.1 Profile Requirement Item: MIME Headers

[EBXML-MSG] Appendix B.3.2 Sending ebXML Messages over SMTP All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Is any specific content-transfer-encoding required, for MIME body parts which must conform to a 7-bit data path? [Base64 or quoted-printable, for example.] Not applicable. This specification only supports the HTTP transport protocol.
If other than "ebXML" what must the SOAPAction SMTP header field contain? Not applicable. This specification only supports the HTTP transport protocol.
What additional MIME headers must be included amongst the SMTP headers? Not applicable. This specification only supports the HTTP transport protocol.
Alignment (empty)
Test References (empty)
Notes (empty)

5.13 Profile Requirement Item: SMTP Confidentiality and Security

[EBXML-MSG] Appendix B.3.4, B.3.5 All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Header elements MIME parts
What SMTP access control mechanisms are required? [Refer to item 4.1.4.8 in Security section.] Not applicable. This specification only supports the HTTP transport protocol.
Is transport-layer security required for SMTP, and what are the specifics of its use? [Refer to item 4.1.4.6 in Security section.] Not applicable. This specification only supports the HTTP transport protocol.
Alignment (empty)
Test References (empty)
Notes (empty)

6. Operational Profile

This section defines the operational aspect of the profile: type of deployment with which the profile which is mentioned above is supposed to operate with, expected or required conditions of operations, usage context, etc.

6.1 Deployment and Processing requirements for CPAs

All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Is a specific registry for storing CPA's required? If so, provide details. Pending.
Is there a set of predefined CPA templates that can be used to create given Parties’ CPA's? It is highly recommended to use the “CPA Register” facility. A web-based program is available by which CPA's are created and stored. See https://cparegister.minvenj.nl/logius See https://www.logius.nl/diensten/digikoppeling/documentatie for information about the CPA Creation facility (document is written in Dutch). In addition to this there is a Best Practices document with information about the use of CPA's.
Is there a particular format for file names of CPA's, in case that file name is different from CPA-ID value? No recommendation.
Others It is required to specify the resulting ebMS collaboration with a CPA. It is required that all actions within a CPA make use of (one and) the same default channel for sending acknowledgements. This default channel can only support one specific profile within a CPA (for instance either osb-rm-s or osb-rm, not both within one CPA). As a result, when there are actions which are based on different profiles (for instance osb-rm-s and osb-be) and the profiles for the acknowledgements are different as well (for instance osb-rm-s and osb-be), multiple CPA's must be created.

6.2 Security Profile

All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Which security profiles are used, and under what circumstances (for which Business Processes)? [Refer to Appendix C of Message Service Specification. May be partially captured by BPSS isConfidential, is Tamperproof, isAuthenticated definitions.] Security profile 3 [ebMS 2.0] Appendix C]: “Sending MSH authenticates and both MSHs negotiate a secure channel to transmit data” must be applied. The HTTPS connection uses encryption to provide in transit confidentiality regarding the complete ebXML message and performs both certificate-based Client and Server authentication during the TLS handshake.
(section 4.1.5) Are any recommendations given, with respect to protection or proper handling of MIME headers within an ebXML Message? Not applicable. No additional recommendations made.
Are any specific third-party security packages approved or required? No recommendation made.
Whichsecurity and management policies and practices are recommended? Pending.
Any particular procedure for doing HTTP authentication, e.g. if exchanging name and password, how? Besides the client authentication in HTTPS, no additional procedures are applied.
Others (empty)

6.3 Reliability Profile

All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
If reliable messaging is required, by what method(s) may it be implemented? [The ebXML Reliable Messaging protocol, or an alternative reliable messaging or transfer protocol.] Not applicable
Which Reliable Messaging feature combinations are required? [Refer to Section 6.6 of Message Service Specification.]
Others

6.4 Error Handling Profile

[EBXML-MSG] Section 4.2.4.2 All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
(Section 4.2.4.2) Should errors be reported to a URI which is different from the one identified within the From element? What are the requirements for the error reporting URI and the policy for defining it? No recommendation made
What is the policy for error reporting? In case an error message cannot be delivered, what other means are used to notify the party, if any? Pending.
(Appendix B.4) What communication protocol-level error recovery is required, before deferring to Reliable Messaging recovery? [For example, how many retries should occur in the case of failures in DNS, TCP connection, server errors, timeouts; and at what interval?] Pending.
Others

6.5 Message Payload and Flow Profile

All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
What are typical and maximum message payload sizes which must be handled? (maximum, average) Some ebXML Messaging products have performance and scalability issues with payloads larger than a (single digit) megabyte in size. Some partners may need to bridge incoming ebXML Message flows to other (enterprise) messaging protocols which have message size limits. Firewalls and other networking equipment may also (implicitly) impose size limits.
What are typical communication bandwidth and processing capabilities of an MSH for these Services? No recommendation made.
Expected Volume of Message flow (throughput): maximum (peak), average? No recommendation made.
(Section 2.1.4) How many Payload Containers must be present? Messages may contain one or more payload containers
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? Each payload container will get a MIME type reflecting the type of the ‘content’ it contains.
How is each container distinguished from the others? [By a fixed ordering of containers, a fixed Manifest ordering, or specific Content-ID values.]. Any expected relative order of attachments of various types? No recommendation made.
Others

6.6 Additional Messaging Features beyond ebMS Specification

All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Are there additional features out of specification scope, whichare part of this messaging profile, as an extension to the ebMS profiling? No.

6.7 Additional Deployment or Operational Requirements

All profiles:
Best effort,
Reliable Messaging,
End-to-End Security
Operational or deployment aspects which are object to further requirements or recommendations. Pending.

7. Conformiteit

Naast onderdelen die als niet normatief gemarkeerd zijn, zijn ook alle diagrammen, voorbeelden, en noten in dit document niet normatief. Verder is alles in dit document normatief.

8. Lijst met figuren

A. Referenties

A.1 Normatieve referenties

[DK-Architectuur]
Digikoppeling Architectuur. Logius. URL: https://gitdocumentatie.logius.nl/publicatie/dk/architectuur/
[DK-beveiliging]
Digikoppeling Beveiligingsstandaarden en voorschriften. Logius. URL: https://gitdocumentatie.logius.nl/publicatie/dk/beveilig/
[EBXML-MSG]
OASIS ebXML Message Service Specification. Ian Jones; Brian Gibb; David Fischer. 1 April 2002. URL: https://www.oasis-open.org/committees/download.php/272/ebMS_v2_0.pdf
[PKI-CA]
Aansluiten als Trust Service Provider. Logius. URL: https://www.logius.nl/domeinen/toegang/aansluiten-als-trust-service-provider
[PKIO-PvE]
Certificate Policy/Programme of Requirements PKIoverheid. Logius. URL: https://por.pkioverheid.nl/
[rfc2392]
Content-ID and Message-ID Uniform Resource Locators. E. Levinson. IETF. August 1998. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc2392
[rfc5322]
Internet Message Format. P. Resnick, Ed.. IETF. October 2008. Draft Standard. URL: https://www.rfc-editor.org/rfc/rfc5322
[SOAP]
SOAP Specifications. W3C. 8 May 2000. W3C Working Group Note. URL: https://www.w3.org/TR/SOAP/
[xml-exc-c14n]
Exclusive XML Canonicalization Version 1.0. John Boyer; Donald Eastlake; Joseph Reagle. W3C. 18 July 2002. W3C Recommendation. URL: https://www.w3.org/TR/xml-exc-c14n/
[xmldsig-core-20020212]
XML-Signature Syntax and Processing. Donald Eastlake; Joseph Reagle; David Solo et al. W3C. 12 February 2002. W3C Recommendation. URL: https://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
[xmlenc-core]
XML Encryption Syntax and Processing. Donald Eastlake; Joseph Reagle. W3C. 10 December 2002. W3C Recommendation. URL: https://www.w3.org/TR/xmlenc-core/

A.2 Informatieve referenties

[Deployment Guide 1.1]
Deployment Profile Template For OASIS ebXML Message Service 2.0. Pete Wenzel; Jacques Durand. OASIS. June 2005. URL: http://www.oasis-open.org/apps/org/workgroup/ebxml-iic-deployment-profile-template-intro-100406.doc
[ebMS3]
Collaboration-Protocol Profile and Agreement Specification Version 2.0. Ian Jones; Pete Wenzel. Oasis. October 2007. URL: https://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_core-3.0-spec-os.html
[UMMR10]
UMM Revision 10. . UN/CEFACT. 2001. URL: https://unece.org/DAM/cefact/umm/UMM_Revision_10_2001.zip
[UMMUG]
UN/CEFACT Modeling Methodology (UMM) User Guide. . UN/CEFACT. 2003. URL: https://www.unece.org/fileadmin/DAM/cefact/umm/UMM_userguide_220606.pdf
Logius Standaard - Vastgestelde versie