OSB Koppelvlakstandaard ebms OSB versie 1.1

OSB Koppelvlakstandaard ebMS OSB versie 1.1

OverheidsServiceBus

OSB Koppelvlakstandaard ebMS versie 1.1

1 van 64

Inhoudsopgave Inhoudsopgave..............................................................................................................................................2 1

Inleiding......................................................................................................................................................5

1.1 1.2 1.3 1.4 1.5

2

Koppelvlakstandaard ebMS.....................................................................................................................9

2.1 2.2 2.3 2.4 2.5 2.6 2.7 3

Doel en Doelgroep................................................................................................................5 Opbouw OSB documentatie.................................................................................................5 De OverheidsServiceBus ....................................................................................................7 Koppelvlak & koppelvlakstandaard......................................................................................8 Opbouw van dit document....................................................................................................8 Status.......................................................................................................................................8 Gehanteerde terminologie: Glossary.......................................................................................8 Website ..................................................................................................................................8 Inleiding................................................................................................................................9 Doel van dit document..........................................................................................................9 Ondersteunde varianten.....................................................................................................10 Berichtuitwisselpatronen....................................................................................................10 Gerelateerd werk................................................................................................................11 Beveiligingsaspecten..........................................................................................................11 Format van dit document....................................................................................................11

Profiling the Modules of ebMS 2.0.........................................................................................................13

3.1 3.2 3.3

Core Modules.....................................................................................................................13 Additional Modules.............................................................................................................15 Communication Protocol Bindings.....................................................................................18 Profile Requirement Item: Transport Protocol.......................................................................18 3.4 Module: Core Extension Elements.....................................................................................19 Profile Requirement Item: PartyID.........................................................................................19 Profile Requirement Item: Role..............................................................................................21 Profile Requirement Item: CPAId...........................................................................................22 Profile Requirement Item: ConversationId.............................................................................23 Profile Requirement Item: MessageID...................................................................................24 Profile Requirement Item: Service.........................................................................................24 Profile Requirement Item: Action...........................................................................................25 Profile Requirement Item: Timestamp...................................................................................26 Profile Requirement Item: Description...................................................................................27 Profile Requirement Item: Manifest.......................................................................................27 Profile Requirement Item: Reference....................................................................................28 Profile Requirement Item: Reference/Schema......................................................................29 Profile Requirement Item: Reference/Description.................................................................29 3.5 Module: Security.................................................................................................................31 Profile Requirement Item: Signature generation...................................................................31

OverheidsServiceBus


2 van 64

Profile Requirement Item: Persistent Signed Receipt...........................................................32 Profile Requirement Item: Non Persistent Authentication.....................................................33 Profile Requirement Item: Non Persistent Integrity...............................................................34 Profile Requirement Item: Persistent Confidentiality.............................................................34 Profile Requirement Item: Non Persistent Confidentiality.....................................................35 Profile Requirement Item: Persistent Authorization...............................................................36 Profile Requirement Item: Non Persistent Authorization.......................................................36 Profile Requirement Item: Trusted Timestamp......................................................................37 3.6 Module : Error Handling.....................................................................................................38 Profile Requirement Item:......................................................................................................38 3.7 Module : SyncReply............................................................................................................39 Profile Requirement Item: SyncReply....................................................................................39 3.8 Module : Reliable Messaging.............................................................................................40 Profile Requirement Item: SOAP Actor attribute...................................................................40 Profile Requirement Item: Signed attribute............................................................................40 Profile Requirement Item: DuplicateElimination....................................................................41 Profile Requirement Item: Retries and RetryInterval.............................................................42 Profile Requirement Item: PersistDuration............................................................................43 Profile Requirement Item: Reliability Protocol.......................................................................44 3.9 Module : Message Status...................................................................................................45 Profile Requirement Item: Status Request message............................................................45 Profile Requirement Item: Status Response message..........................................................45 3.10 Module : Ping Service......................................................................................................47 Profile Requirement Item: Ping-Pong Security......................................................................47 3.11 Module : Multi-Hop...........................................................................................................48 Profile Requirement Item: Use of intermediaries...................................................................48 Profile Requirement Item: Acknowledgements......................................................................49 3.12 SOAP Extensions.............................................................................................................51 Profile Requirement Item: #wildCard, Id................................................................................51 3.13 MIME Header Container...................................................................................................52 Profile Requirement Item: charset.........................................................................................52 3.14 HTTP Binding...................................................................................................................53 Profile Requirement Item: HTTP Headers.............................................................................53 Profile Requirement Item: HTTP Response Codes...............................................................53 Profile Requirement Item: HTTP Access Control..................................................................54 Profile Requirement Item: HTTP Confidentiality and Security..............................................55 3.15 SMTP Binding...................................................................................................................56 Profile Requirement Item: MIME Headers.............................................................................56 Profile Requirement Item: SMTP Confidentiality and Security..............................................56 3.16 Deployment and Processing requirements for CPAs.......................................................58 3.17 Security Profile.................................................................................................................58 3.18 Reliability Profile...............................................................................................................59

OverheidsServiceBus


3 van 64

3.19 3.20 3.21 3.22 4

Error Handling Profile.......................................................................................................59 Message Payload and Flow Profile..................................................................................60 Additional Messaging Features beyond ebMS Specification...........................................61 Additional Deployment or Operational Requirements......................................................61

References...............................................................................................................................................62

4.1 4.2

Normative...........................................................................................................................62 Non-normative....................................................................................................................62

OverheidsServiceBus


4 van 64

1 Inleiding 1.1 Doel en Doelgroep Dit document beschrijft de functionele specificaties voor de OSB ebMS Deployment Profile, onderdeel van OSB 1.0. Het document is bestemd voor architecten en ontwikkelaars die op basis van ebMS gegeven willen uitwisselen via de OverheidsServiceBus (OSB). Alle OSB webservices die op ebMS gebaseerd zijn, moeten conformeren aan de Koppelvlakstandaard ebMS. Deze wordt tot in detail in dit document gespecificeerd. Het doel van dit document is om ontwikkelaars te informeren wat deze koppelvlakstandaard nu precies inhoudt en waar zij zich aan moeten conformeren. Het document is bestemd voor architecten en ontwikkelaars die op basis van ebMS gegevens willen uitwisselen via de OSB. Het gaat hierbij om zowel service providers als service requesters (clients).

1.2 Opbouw OSB documentatie De OSB is beschreven in een set van documenten. Deze set is als volgt opgebouwd.

OverheidsServiceBus


5 van 64

NORA

Identificatie en Authenticatie

OSB Architectuur

OSB Koppelvlak Standaarden

OSB Compliance Voorzieningen

ebMS

ebMS

WUS

OSB Service Register Specificatie

OSB Gateway Specificatie

WUS

Dit document beschrijft de ebMS Koppelvlakstandaard.

OverheidsServiceBus


6 van 64

1.3 De OverheidsServiceBus Deze paragraaf bevat zeer beknopt een aantal hoofdpunten uit de overige documentatie. Doel en scope van de OSB De OverheidsServiceBus biedt de mogelijkheid om op een sterk gestandaardiseerde wijze berichten uit te wisselen tussen service aanbieders (service providers) en service afnemers (service requesters of consumers). De uitwisseling tussen service providers en requesters wordt in drie lagen opgedeeld: •

Inhoud: Op deze laag worden de afspraken gemaakt de inhoud van het uit te wisselen bericht, dus de structuur, semantiek, waardebereiken etc. De OSB houdt zich niet met de inhoud bezig, ‘heeft geen boodschap aan de boodschap’.

•

Logistiek: Op deze laag bevinden zich de afspraken betreffende transportprotocollen (HTTP), messaging (SOAP), beveiliging (authenticatie en encryptie)en betrouwbaarheid. Dit is de OSB-laag.

•

Transport: deze laag verzorgt het daadwerkelijke transport van het bericht.

De OSB richt zich dus uitsluitend op de logistieke laag. Deze afspraken komen in de koppelvlakstandaarden en andere voorzieningen. De architectuur van de Gateway is beschreven in het document “Architectuur OSB”.

Leidend principe (requirement) De koppelvlakstandaarden dienen te leiden tot een maximum aan interoperabiliteit met een minimum aan benodigde ontwikkelinspanning. Daarom wordt gekozen voor bewezen interoperabele internationale standaarden. De OSB maakt berichtenuitwisseling mogelijk op basis van de ebXML/ebMS en WUS families van standaarden inclusief de daarbij behorende verwante standaarden. Aan te sluiten overheidsorganisaties hebben aangegeven dat zij op een uniforme manier (één stekker) willen aansluiten op de OSB. Organisaties die beschikken over eigen middleware (ESB, broker) kunnen de aansluiting aan de OSB, de adapters, in het algemeen realiseren via voorzieningen in die middleware. Voor andere organisaties is afgesproken dat de OSB Gateway beschikbaar komt. Deze biedt ‘intern”, d.w.z. naar de organisatie toe, die een stekker biedt, gebaseerd op de protocollen WUS-lite en JMS, en extern, d.w.z. naar de OSB toe communiceren op basis van de OSB koppelvlakstandaarden.

OverheidsServiceBus


7 van 64

1.4 Koppelvlak & koppelvlakstandaard Een koppelvlak is een interface die volgens vergaande 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 zijn. Een van de belangrijkste eisen die door de overheid gesteld wordt 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 geleverde software gebruik gemaakt kan worden. Voor de Bus, 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 standaards, 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). Specificatie van de koppelvlakstandaard De koppelvlakspecificatie beschrijft de eisen waar de adapters aan moeten voldoen om interoperabel met elkaar te kunnen communiceren. OSB gaat over logistiek, dus over de envelop en niet over de inhoud. De hele set info die tezamen nodig is voor een complete generieke OSB 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 ebMS profiel zoals dat gekozen is voor de OSB. Status Deze versie van de OSB koppelvlakstandaard is definitief. Deze versie is inhoudelijk gelijk aan de versie 0.92, die is vastgesteld door het College Standaardisatie. Gehanteerde terminologie: Glossary Voor de definities die binnen het OSB project gehanteerd worden, zie de ‘OSB Glossary’. Website Dit document en andere documentatie is beschikbaar op www.overheidsservicebus.nl .

OverheidsServiceBus


8 van 64

2 Koppelvlakstandaard ebMS 2.1 Inleiding Dit document specificeert de Koppelvlakstandaard ebMS voor berichtenuitwisseling over de OverheidsServiceBus als een toepassing van de ISO 15000-2 standaard, de ebXML Message Service Specification versie 2.0 [ISO 15000-2]. De OSB 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 [ISO 15000-2] 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 configuratie features 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 de OSB. 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 Doel van dit document Dit document biedt organisaties die gebruik gaan maken van de OSB 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: • •

Not Applicable. Dit is voor onderdelen die niet relevant zijn voor de OSB, of voor mogelijkheden die niet gebruikt worden. No Recommendation: geeft aan dat er geen wijziging of voorkeur voor een bepaalde invulling van het onderdeel is op het algemene niveau waar dit document zich op richt.

OverheidsServiceBus


9 van 64

•

Specifieke toepassingen van deze specificatie (voor specifieke berichtstromen) zullen hier in sommige gevallen wel nog aanvullende eisen voor stellen. Pending: voor onderdelen die nog nader onderzocht worden en mogelijk in toekomstige versies nader uitgewerkt worden.

In de Engelse tekst dienen de woorden “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” te worden geïnterpreteerd zoals beschreven in [RFC2119].

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 de praktijk wenselijk is. Om redenen van interoperabiliteit, eenvoud en overzichtelijkheid onderscheidt deze specificatie een tweetal 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 de OSB versie 1 zal moeten voldoen aan één van de volgende OSB ebMS profielen: •

•

Best Effort: dit zijn asynchrone uitwisselingen die geen faciliteiten voor betrouwbaarheid (ontvangstbevestigingen, duplicaateliminatie etc.) vereisen. Voorbeelden zijn toepassingen waar het eventueel verloren raken van sommige berichten niet problematisch is en waar snelle verwerking gewenst is. Reliable Messaging: asynchrone uitwisseling met ontvangst bevestigingen en duplicaateliminatie door de ontvangende message handler. Dit profiel is onder meer geschikt voor alle berichtenstromen die leiden tot updates van gegevensverzamelingen.

In beide profielen wordt vertrouwelijkheid en authenticatie van zender en ontvanger gerealiseerd op transportniveau. Beide profielen maken gebruiken van HTTPS als transport kanaal en beide profielen zijn asynchroon.

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 informatieverspreiding en notificaties, die geen antwoordbericht veronderstellen. Two Way uitwisselingen ondersteunen bedrijfstransacties van het type VraagAntwoord, 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

OverheidsServiceBus


10 van 64

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 gebruikmaken van het Best Effort profiel of het Reliable Messaging profiel.

2.5 Gerelateerd werk Dit document borduurt voort op eerdere toepassingen van ebXML Messaging in de strafrechtketen, de keten openbare orde en veiligheid en de vreemdelingenketen en is verwant aan de Justitiestandaard Asynchroon Berichtenverkeer [JAB 2.0].

2.6 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 algorithmen waarop deze standaarden zijn gebaseerd, is het van belang dat deze specificatie regelmatig op geldigheid hiervan wordt bezien. De specifieke toegepaste referenties zijn: • Advanced Encryption Standard 256-cbc [FIPS 197] • NIST richtlijnen voor sleutelbeheer [NIST-Keys] • RSA-SHA1 [RFC 2437] • Transport Level Security 1.0 [RFC 2246]

2.7 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.

OverheidsServiceBus


11 van 64

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 omdat 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 [ISO 15000-2].

OverheidsServiceBus


12 van 64

3 Profiling the Modules of ebMS 2.0 In this section, users will only specify which modules of the source specification are used in this profile (i.e. modules that business partners need to use or support in order to comply with the profile and communicate with others who do comply). For each used module, users also specify whether the module has been profiled or not. If so, some profiling details should be given for this module in section 3 or 4.

3.1 Core Modules Module Name and Reference Profiling Status Notes

Module Name and Reference Profiling Status

Core Extension Elements (section 3)

Usage: <required / optional / never used in this profile> Profiled:

Security Module (section 4.1)



OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging

Support for the Core Extension Elements of ebXML Messaging 2.0 is required.


The Security Module is never used in these profiles.

Page

OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging Security profile 3: “Sending MSH authenticates and both MSH' s negotiate a secure channel to transmit data” must be used. The HTTPS connection uses encryption to provide in transit confidentiality of the complete ebXML message and performs certificate-based Client and Server authentication during the TLS handshake.

Notes

Module Name and Reference Profiling Status Notes

SyncReply Module (section 4.3)




SyncReply is never used in these profiles. All messages, including acknowledgments and error messages, are sent asynchronously. 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.

Page

3.2 Additional Modules Module Name and Reference Profiling Status

Reliable Messaging Module (section 6)


Notes


Message Status Service (section 7)




Never used in this profile. Reliable messaging profile 8, Best Effort.

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.

The ebXML reliable messaging protocol is not used. Acknowledgment messages must not be sent or requested, and the receiver should not eliminate duplicate messages.

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 on multi-hop module) 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.


Optional. Message Status Service is not required in these profiles.

Page


Notes




Ping Service (section 8)


Message Order (section 9)


Multi-Hop (section 10)




Optional. Ping Service is not required in these profiles.


Message Order is optional in these profiles.

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. OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging

Never used in this profile.

Page

Notes


OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging These profiles use asynchronous communication for business messages, acknowledgments and error messages. This protocol is therefore compatible with asychronous, transparent, store-and-forward ebXML Messaging (or other SOAPbased) intermediaries. However, this document only specifies functionality of ebXML message endpoints.

Page

3.3 Communication Protocol Bindings Profile Requirement Item: Transport Protocol

Specification Feature Specification Reference Profiling (a)

Profiling (b)

Profiling (c)

Profiling (d) Profiling (e)

Alignment Test References Notes

Header elements:


ebMS 2, Appendix B Is HTTP a required or allowed transfer protocol? (See section B.2 for specifics of this protocol.) Is HTTPS a required or allowed transfer protocol? (See section B.2 for specifics of this protocol.) Is (E)SMTP a required or allowed transfer protocol? (See section B.3 for specifics of this protocol.) If SMTP, What is needed in addition to the ebMS minimum requirements for SMTP? Are any transfer protocols other than HTTP and SMTP allowed or required? If so, describe the protocol binding to be used.


Never used in this profile. HTTPS is used instead.

HTTPS is the required transport protocol.

(E)SMTP is never used in this profile.

Not applicable No other protocols are supported.

Page

3.4 Module: Core Extension Elements Profile Requirement Item: PartyID

Specification Feature

Specification Reference Profiling (a)

In message Header: / SOAP:Header/eb:MessageHeader/eb:From/e b:PartyID / SOAP:Header/eb:MessageHeader/eb:To/eb:P artyID Is a specific standard used for party identification? Provide details. ebMS 2, section 3.1.1.1 PartyId Element 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 (OverheidsIdentificatieNummer- Governmental Identification Number) for the 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 on the OSB. OIN stands for OverheidsIdentificatieNummer and is maintained by the GBO.overheid in the OSB Service Register (OSR). (When ready, the Netherlands Business Registry (Nieuwe HandelsRegister: NHR) will take over the registration, until then the OSR is used for the OIN administration.) The number is unique and allows identification of partners, even if they are not themselves legal entities but departments or units of larger organizations.


Page

Profiling (b) Profiling (c)


Should multiple PartyID elements be present in From and To elements? 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/gl n">1234567890128 appears as PartyID element in CPA. (c) appears as PartyID/@type in CPA



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

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:partyidtype 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 at the same time, with no requirement that the codes in those systems do not overlap.

Page

Profile Requirement Item: Role


Specification Reference Profiling

Alignment

Test References Notes

Header elements: / SOAP:Header/eb:MessageHeader/eb:From/e b:Role /SOAP:Header/eb:MessageHeader/eb:To/eb: Role ebMS 2, section 3.1.1.2 “Role Element” 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. <eb:Role>http:/www.eanucc.org/roles/seller [Per-process; may reference Role values in BPSS [BPSS] definitions. Appears as Role/@name in CPA.]



Business process is out of scope for (this version of the) OSB. 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 diffferent roles, different contracts (CPA' s) must be used.

Page

Profile Requirement Item: CPAId

Specification Feature Specification Reference Profiling


Header elements: /SOAP:Header/eb:MessageHeader/eb:CPAId ebMS 2, section 3.1.2 What identification scheme is used for the CPAId, and what form should it take? If 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 Appears as CollaborationProtocolAgreement/ @cpaid in CPA.



The proposed EAN•UCC is recommended as a good practice.

Page

Profile Requirement Item: ConversationId



Profiling (b)

Alignment


Header elements: / SOAP:Header/eb:MessageHeader/eb:Conver sationId ebMS 2, section 3.1.3 What is the user definition of a Conversation? What is the business criterion used to correlate messages considered parts of the same conversation? 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 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? If BPSS is used, ConversationID typically maps to a business transaction. Is that the case? Does it map to a business collaboration instead?



[ISO 15000-2] requires that request messages, response messages, and any acknowledgments and error messages have the same value for ConversationID.

No recommendation made.

No recommendation made. Business process is out of scope for OSB.

ConversationId is a required ebXML message header element.

Page

Profile Requirement Item: MessageID




Header elements: / SOAP:Header/eb:MessageHeader/eb:Messag eData/eb:MessageID ebMS 2, section 3.1.6.1 Although there is no requirement for an MSH to divert control regarding a MessageID to an application, some implementations may allow this. In that case, is there any requirement concerning the source of this ID? Are there any length and format restrictions if the ID is generated?


No recommendation made. The value of MessageID does not need to meet any requirements beyond the string format specified in [ISO 15000-2] and the global uniqueness constraint of [RFC 2822].

Profile Requirement Item: Service


Specification Reference

Header elements: / SOAP:Header/eb:MessageHeader/eb:Service / SOAP:Header/eb:MessageHeader/eb:Service /@type ebMS 2, section 3.1.4



Page

Profiling (a)

Profiling (b)


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? Is there a defined "type" for Service elements? If so, what value must the type attribute contain? Appears as Service element in CPA Appears as Service/@type in CPA

OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging No recommendation made.

The text content of the Service element must not contain white space.

Profile Requirement Item: Action

Specification Feature Specification Reference

Header elements: /SOAP:Header/eb:MessageHeader/eb:Action ebMS 2, section 3.1.5


OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging The text content of the Action element must not contain white space.

Page

Profiling


Are actions defined for each party to each business process? List them, or provide a reference to the source of these values. [Perprocess; one 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 Appears as ThisPartyActionBinding/@action in CPA.]

OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging No recommendation made.

Profile Requirement Item: Timestamp


Specification Reference Profiling Alignment

Header elements: / SOAP:Header/eb:MessageHeader/eb:Messag eData/eb:Timestamp /SOAP:Header/eb:MessageHeader/ eb:Acknowledgment/eb:Timestamp ebMS 2, section 3.1.6.2, 6.3.2.2, 6.4.5, 7.3.2 Must Timestamp include the ' Z'(UTC) identifier?



Timestamps must include the ‘Z’ (UTC) identifier.

Page


Test References Notes Profile Requirement Item: Description




Header elements: / SOAP:Header/eb:MessageHeader/eb:Descrip tion ebMS 2, section 3.1.8 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.

Profile Requirement Item: Manifest


Header elements: /SOAP:Body/eb:Manifest ebMS 2, section 3.2.2



Page

Profiling (a)

Profiling (b) Alignment Test References Notes

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? Is there any restriction on the range of value for xlink:reference (e.g. nothing other than content ID references)? Must a URI that cannot be resolved be reported as an error?

OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging Manifest elements must only reference business documents or other payloads which are included in the ebXML message as a MIME part. While [ISO 15000-2] 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 option is not supported in these profiles. A Content ID URI reference that cannot be resolved must be treated as an error.

XML or other business documents can have references to other resources which are not part of the ebXML message. It is up to the receiving application to interpret these references. Any such mechanism is out of scope for OSB. Profile Requirement Item: Reference

Specification Feature Specification Reference Profiling (a) Profiling (b) Alignment Test References Notes

Header elements: /SOAP:Body/eb:Manifest/eb:Reference ebMS 2, section 3.2.1 Is the xlink:role attribute required? What is its value? Are any other namespace-qualified attributes required?


OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging Only the Content ID reference mechanism [RFC 2392] is allowed.

Not applicable. The xlink:role attribute is not required. Not applicable. No other namespace-qualified attributes are allowed.

Page

Profile Requirement Item: Reference/Schema




Header elements: / SOAP:Body/eb:Manifest/eb:Reference/eb:Sch ema ebMS 2, section 3.2.1.1 Are there any Scheme elements required? If so, what are their location and version attributes?


Scheme elements are not required. The OSB does not perform XML scheme validation.

Profile Requirement Item: Reference/Description


Specification Reference Profiling Alignment Test References Notes

Header elements: / SOAP:Body/eb:Manifest/eb:Reference/eb:Des cription ebMS 2, section 3.2.1.2 Are any Description elements required? If so, what is their content?



Description elements are optional. They may be ignored by any receiving message service handler.

Page


Page

3.5 Module: Security Profile Requirement Item: Signature generation OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging


Header elements: /SOAP:Header/Signature ebMS 2, section 4.1.4.1 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.

Profiling (b)

Are additional Signature elements required, by whom, and what should they reference? What canonicalization method(s) must be applied to the data to be signed? [Recommended method is "http://www.w3.org/TR/2001/REC-xml-c14n20010315".] What canonicalization method(s) must be applied to each payload object, if it differens from the above mentioned? What signature method(s) must be applied? What Certificate Authorities (issuers) are allowed or required to sign certificates? Are direct-trusted (or self-signed) signing certificates allowed? What certificate verification policies and procedures must be followed?

Not applicable

Profiling (c)

Profiling (d)

Profiling (e) Profiling (f) Profiling (g) Profiling (h)


Not applicable

Not applicable

Not applicable Not applicable Not applicable The requirements as stated by the PKIOverheid [PKI-Policy].have to be used.

Page

Alignment


(a) Appears as BusinessTransactionCharacteristics/@isAuthe nticated=persistent and BusinessTransactionCharacteristics/@isTamp erProof=persistent in CPA


Applications submitting data to, or receiving data from, OSB 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 those cases, the OSB is not aware of the presence of signatures and does not perform signature verification. Profile Requirement Item: Persistent Signed Receipt


Profiling (b)

Header elements: /SOAP:Header/eb:Signature ebMS 2, section 4.1.4.2 Is a digitally signed Acknowledgment message required? [Yes, for Security Services Profiles 7, 8, 10, 12, 14, 15, 17, 1921. See the items beginning with Section 4.1.4.1 for specific Signature requirements. ] If so, what is the Acknowledgment or Receipt scheme?



Not applicable

Not applicable

Page

Alignment


Appears as BusinessTransactionCharacteristics/@isNonR epudiationReceiptRequired=persistent in CPA.


Profile Requirement Item: Non Persistent Authentication


Alignment


Header elements: /SOAP:Header/eb:Signature ebMS 2, section 4.1.4.3 Are communication channel authentication methods required? [Yes, for Security Services Profiles 2-5.] Which methods are allowed or required? [Appears as BusinessTransactionCharacteristics/@isAuthe nticated=transient in CPA.]



Client and Server authentication is required using HTTPS and TLS 1.0 [RFC 2246]. Message service handlers should be able to operate in SSL v3 backward compatibility mode.

Page

Profile Requirement Item: Non Persistent Integrity


Alignment


Header elements: /SOAP:Header/eb:Signature ebMS 2, section 4.1.4.4. Are communication channel integrity methods required? [Yes, for Security Services Profile 4.] Which methods are allowed or required? [Appears as BusinessTransactionCharacteristics/@isTamp erproof=transient in CPA.]


Not applicable

Profile Requirement Item: Persistent Confidentiality


Profiling (b)

Header elements: /SOAP:Header/eb:Signature ebMS 2, section 4.1.4.5 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.] Is payload confidentiality (encryption) required? [Yes, for Security Services Profiles 13, 14, 16, 17, 21, 22.] Which methods are allowed or required?



Not applicable

Not applicable.

Page

Alignment


(b) [Appears as BusinessTransactionCharacteristics/@isConfi dential=persistent in CPA.]


Applications submitting data to, or receiving data from, OSB 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 the OSB. Profile Requirement Item: Non Persistent Confidentiality


Alignment


Header elements: /SOAP:Header/eb:Signature ebMS 2, section 4.1.4.6 Are communication channel confidentiality methods required? [Yes, for Security Services Profiles 3, 6, 8, 11, 12.] Which methods are allowed or required? [Appears as BusinessTransactionCharacteristics/@isConfi dential=transient in CPA.]



HTTPS using TLS 1.0 [RFC 2246] Message service handlers should support SSL v3 compatibility mode.

Page

Profile Requirement Item: Persistent Authorization


Alignment


Header elements: /SOAP:Header/eb:Signature ebMS 2, section 4.1.4.7 Are persistent authorization methods required? [Yes, for Security Services Profiles 18-21.] Which methods are allowed or required? [Appears as BusinessTransactionCharacteristics/@isAutho rizationRequired=persistent in CPA.]


Not applicable

Profile Requirement Item: Non Persistent Authorization


Alignment

Header elements: /SOAP:Header/eb:Signature ebMS 2, section 4.1.4.8 Are communication channel authorization methods required? [Yes, for Security Services Profile 2.] Which methods are allowed or required? [Appears as BusinessTransactionCharacteristics/@isAutho rizationRequired=transient in CPA.]



TLS [RFC 2246] client and server authentication must be applied as described in section in .

Page


Test References Notes Profile Requirement Item: Trusted Timestamp



Header elements: /SOAP:Header/eb:Signature ebMS 2, section 4.1.4.9 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

Applications submitting data to, or receiving data from, OSB 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 OSB functionality. Any valid ebXML message must contain an eb:TimeStamp as part of the eb:MessageData.

Page

3.6 Module : Error Handling Profile Requirement Item:


Specification Reference Profiling (a) Profiling (b) Profiling (c)


Header elements: /SOAP:Header/eb:ErrorList/eb:Error /SOAP:Header/eb:ErrorList/ eb:Error/@codeContext /SOAP:Header/eb:ErrorList/ eb:Error/@errorCode ebMS 2, section 4.2.3.2. Is an alternative codeContext used? If so, specify If an alternative codeContext is used, what is its errorCode list? When errors should be reported to the sending application, how should this notification be performed (e.g. using a logging mechanism or a proactive callback)?



Not applicable

Not applicable

Page

3.7 Module : SyncReply Profile Requirement Item: SyncReply


Profiling (b)

Alignment


Header elements: /SOAP:Header/eb:SyncReply/ ebMS 2, section 4.3 Is SyncReply mode allowed, disallowed, or required, and under what circumstances? [May be process-specific.] If SyncReply mode is used, are MSH signals, business messages or both expected synchronously? [Affects setting of 6.4.7 syncReplyMode element. Appears as MessagingCharacteristics/@syncReplyMode in CPA.]



Not applicable. SyncReply is not supported in this specification.

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 RefToMessageID header elements encode correlation of request and response messages.

Page

3.8 Module : Reliable Messaging Profile Requirement Item: SOAP Actor attribute


Profiling (b)


Header elements: /SOAP:Header/eb:AckRequested/ ebMS 2, section 6.3.1.1 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.] 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. .

Not applicable

The final recipient MSH returns a receipt acknowledgment message.

Profile Requirement Item: Signed attribute


Header elements: /SOAP:Header/eb:AckRequested/ ebMS 2, section 6.3.1.2 Must MSH Acknowledgments be (requested to be) signed ?



Not applicable

Page


[Appears as MessagingCharacteristics/ @ackSignatureRequested in CPA.]


Profile Requirement Item: DuplicateElimination

Specification Feature Specification Reference Profiling (a) Profiling (b)

Alignment Test References

Header elements: /SOAP:Header/eb:AckRequested/ ebMS 2, section 6.4.1 Is elimination of duplicate messages required? [Yes, for RM Combinations 1-4. .] 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? Appears as MessagingCharacteristics/ @duplicateElimination in CPA



Not applicable

Duplicate Elimination is required. Message ID' s should minimally be kept in persistent storage to prevent duplicate delivery during the time interval during which the From Party MSH may be attempting to resend unacknowledged messages. This interval is (1+Retries)*RetryInterval.

Page

OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging Message ID' s in ebXML are based on [RFC 2822], 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.

Notes

Profile Requirement Item: Retries and RetryInterval


Profiling (b)

Header elements: /SOAP:Header/eb:AckRequested/ ebMS 2, section 6.4.3, 6.4.4 If reliable messaging is used, how many times must an MSH attempt to redeliver an unacknowledged message? What is the minimum time a Sending MSH should wait between retries of an unacknowledged message?


Not applicable

Some organizations using the OSB may not have fulltime 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.


Page

Alignment


(a) [Appears as ReliableMessaging/Retries in CPA.] (b) [Appears as ReliableMessaging/RetryInterval in CPA.]


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 such that any such transport retries have completed first. Profile Requirement Item: PersistDuration



Header elements:


ebMS 2, section 6.4.6 How long must data from a reliably sent message be kept in persistent storage by a receiving MSH, for the purpose of retransmission? [Appears as ReliableMessaging/PersistDuration in CPA.]


Not applicable

That 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.

Page

Profile Requirement Item: Reliability Protocol


Profiling (b)


Header elements: ebMS 2, section 6.5.3, 6.5.7 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? If a DeliveryFailure error message cannot be delivered successfully, how must the error message' s destination party be informed regarding the problem?



The Reliable Messaging Protocol in [ISO 15000-2] must be used. Not applicable Receipt acknowledgment messages are standalone messages. They must not to be bundled with business response messages or other ebXML messages. Each collaborating party is responsible for defining procedures for handling these issues.

Page

3.9 Module : Message Status Profile Requirement Item: Status Request message

Specification Feature Specification Reference Profiling (a) Profiling (b)


Header elements: Eb:MessageHeader/eb:StatusRequest ebMS 2, section 7.1.1 If used, must Message Status Request Messages be digitally signed? Must unauthorized Message Status Request messages be ignored, rather than responded to, due to security concerns?


Not applicable. Digital signing is not supported. No recommendation made.

Profile Requirement Item: Status Response message

Specification Feature Specification Reference Profiling Alignment Test References

Header elements: Eb:MessageHeader/eb:StatusResponse ebMS 2, section 7.1.2 If used, must Message Status Response Messages be digitally signed?



Not applicable. Digital signing is not supported.

Page

Notes



Page

3.10 Module : Ping Service Profile Requirement Item: Ping-Pong Security

Specification Feature Specification Reference Profiling (a) Profiling (b) Profiling (c) Profiling (d)


Header elements: Eb:MessageHeader/eb:Service Eb:MessageHeader/eb:Action ebMS 2, section 8.1, 8.2 If used, must Ping Messages be digitally signed? If used, must Pong Messages be digitally signed? Under what circumstances must a Pong Message not be sent? If not supported or unauthorized, must the MSH receiving a Ping respond with an error message, or ignore it due to security concerns?



If Ping-Pong is used, Ping messages must not be digitally signed If Ping-Pong is used, Pong services must not be digitally signed No recommendation made. No recommendation made

Page

3.11 Module : Multi-Hop Profile Requirement Item: Use of intermediaries


Header elements:

Profiling (b)

What are the values of Retry and RetryInterval between intermediate MSH nodes?


ebMS 2, section 10 Are any store-and-forward intermediary MSH nodes present in the message path?

Alignment Test References


Endpoints connecting to the OSB 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. Not applicable. Any OSB-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 OSBlevel ebXML intermediaries should attempt to forward end-to-end receipts and errors.

Page

OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging Any OSB-level ebXML This profile uses end-to-end reliable messaging. This intermediary may support allows the OSB to recover from any temporary transport retries, for processing failures at the level of intermediaries. instance to handle Upcoming versions of the OSB may support store and temporary TCP or HTTP forward ebXML intermediaries at an infrastructural transport level errors. level. The functionality of these intermediaries is likely This is not required. be limited to fully transparent, asynchronous storeand-forward routing of ebXML messages. In that case, no special processing is required concerning 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.

Notes

Profile Requirement Item: Acknowledgements

Specification Feature Specification Reference Profiling (a) Profiling (b) Profiling (c)

Alignment

Header elements: Eb:MessageHeader/ ebMS 2, section 10.1.1, 10.1.3 Must each intermediary request acknowledgment from the next MSH? Must each intermediary return an Intermediate Acknowledgment Message synchronously? If both intermediary (multi-hop) and endpoint acknowledgments are requested from the To Party, must they both be sent in the same message?



Not applicable. There is no support for ebXML next MSH acknowledgments. Not applicable. There is no support for ebXML next MSH acknowledgments. Not applicable. There is no support for ebXML next MSH acknowledgments.

Page




Page

3.12 SOAP Extensions Profile Requirement Item: #wildCard, Id


Profiling (b)

Profiling (c)


Header elements:


ebMS 2, section 2.3.6, 2.3.7, 2.3.8 (Section 2.3.6) #wildcard Element Content: Are additional namespace-qualified extension elements required? If so, specify. (Section 2.3.7) Is a unique “ID” attribute required for each (or any) ebXML SOAP extension elements, for the purpose of referencing it solely in a digital signature?

Not applicable. No additional namespace-qualified extension elements are required. The toPartyMSH and any intermediaries must ignore any extension elements. 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 [ISO 15000-2].


Page

3.13 MIME Header Container Profile Requirement Item: charset



MIME Header elements: Content-Type ebMS 2, section 2.1.3.2 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

Page

3.14 HTTP Binding Profile Requirement Item: HTTP Headers


Profiling (b) Profiling (c) Alignment Test References Notes

Header elements, MIME parts


ebMS 2, Appendix B.2.2. Is a (non-identity) content-transfer-encoding required for any of the MIME multipart entities? If other than "ebXML" what must the SOAPAction HTTP header field contain? What additional MIME-like headers must be included among the HTTP headers?

Content transfer encoding should not be used.

The value of the SOAPAction HTTP header field MUST be “ebXML” Additional MIME-like headers should not be included within the HTTP header. Any ebXML MSH should ignore any such additional HTTP header.

Profile Requirement Item: HTTP Response Codes




ebMS 2, Appendix B.2.3.


Page

Profiling

What client behaviors should result when 3xx, 4xx or 5xx HTTP error codes are received?


OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging In the event of an HTTP 5xx error code, the MSH must behave according to the recommendations specified in [SOAP1.1]. 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.

Profile Requirement Item: HTTP Access Control





ebMS 2, Appendix B.2.6. Which HTTP access control mechanism(s) are required or allowed? [Basic, Digest, or client certificate (the latter only if transportlayer security is used), for example. Refer to item 4.1.4.8 in Security section. Appears as AccessAuthentication elements in CPA.


Access control is based on client certificate information only. HTTP Basic or Digest authentication are not supported.

Page

Profile Requirement Item: HTTP Confidentiality and Security


Profiling (b)

Profiling (c) Profiling (d) Profiling (e) Profiling (f) Profiling (g) Alignment Test References Notes



ebMS 2, Appendix B.2.7. Is HTTP transport-layer encryption required? What protocol version(s)? [SSLv3, TLSv1, for example. Refer to item 4.1.4.6 in Security section.] What encryption algorithm(s) and minimum key lengths are required?

What Certificate Authorities are acceptable for server certificate authentication? Are direct-trust (self-signed) server certificates allowed? Is client-side certificate-based authentication allowed or required? What client Certificate Authorities are acceptable? What certificate verification policies and procedures must be followed?


Encryption based on HTTPS using TLS 1.0 [RFC 2246] is required. TLS implementations must support SSL v3 backwards compatibility mode.

TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA PKIoverheid maintains a list of approved certificate service providers [PKI-CA]. No Client-side authentication is required. PKIoverheid maintains a list of approved certificate service providers [PKI-CA]. PKIoverheid procedures are described in [PKI-Policy].

Page

3.15 SMTP Binding Profile Requirement Item: MIME Headers


Profiling (b) Profiling (c) Alignment Test References Notes



ebMS 2, Appendix B.3.2.

Not Applicable. This specification only supports the HTTP transport protocol.

Is any specific content-transfer-encoding required, for MIME body parts that must conform to a 7-bit data path? [Base64 or quoted-printable, for example.] If other than "ebXML" what must the SOAPAction SMTP header field contain? What additional MIME headers must be included among the SMTP headers?

Not Applicable.

Not Applicable. Not Applicable.

Profile Requirement Item: SMTP Confidentiality and Security




ebMS 2, Appendix B.3.4, B.3.5 What SMTP access control mechanisms are required? [Refer to item 4.1.4.8 in Security section.]


Not Applicable.

Page

Profiling (b)


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.]


OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging Not Applicable.

Page

3.16 Deployment and Processing requirements for CPAs Is a specific registry for storing CPA' s required? If so, provide details. Is there a set of predefined CPA templates that can be used to create given Parties’ CPA' s? Is there a particular format for file names of CPA' s, in case that file name is different from CPA-ID value? Others

OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging Pending CPA templates are available for the two profiles defined in this specification. Pending

3.17 Security Profile Which security profile(s) 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.] (section 4.1.5) Are any recommendations given, with respect to protection or proper handling of MIME headers within an ebXML Message? Are any specific third-party security packages approved or required? What security and management policies and practices are recommended? Any particular procedure for doing HTTP authentication, e.g. if exchanging name and password, how? OSB Koppelvlakstandaard ebMS versie 1.0

OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging Security profile 3: “Sending MSH authenticates and both MSH's negotiate a secure channel to transmit data” must be applied.

Not applicable. No additional recommendations made.

No recommendation made Pending Not applicable.

Page

Others


3.18 Reliability Profile If reliable messaging is required, by which method(s) may it be implemented? [The ebXML Reliable Messaging protocol, or an alternative reliable messaging or transfer protocol.] Which Reliable Messaging feature combinations are required? [Refer to Section 6.6 of Message Service Specification.]

OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging Not applicable The ebXML reliable messaging protocol must be used. Reliable Messaging profile 2: Duplicate elimination Yes AckRequested ToPartyMSH Yes AckRequested NextMSH No

Others

3.19 Error Handling Profile (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? 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?


OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging No recommendation made

Pending.

Page

(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?] Others

OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging Pending.

3.20 Message Payload and Flow Profile What are typical and maximum message payload sizes that must be handled? (maximum, average)

What are typical communication bandwidth and processing capabilities of an MSH for these Services? Expected Volume of Message flow (throughput): maximum (peak), average? (Section 2.1.4) How many Payload Containers must be present?

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?


OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging 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. No recommendation made

Messages other than standalone receipt acknowledgement messages and error messages must contain exactly one payload container. This limit is imposed in order to facilitate bridging to other protocols at the enterprise level which may not support multiple payloads natively. The payload must be of type “application/xml”. I.e. this version of the OSB is limited to payloads consisting of a single XML business document.

Page

How is each container distinguished from the others? [By a fixed ordering of containers, a fixed Manifest ordering, or specific Content-ID values.]. Is there any expected relative order of attachments of various types? Others

OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging No recommendation made

3.21 Additional Messaging Features beyond ebMS Specification Are there additional features out of specification scope, which are part of this messaging profile, as an extension to the ebMS profiling?

OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging No No

3.22 Additional Deployment or Operational Requirements Operational or deployment aspects which are object to further requirements or recommendations.


OSB profiles for ebXML Messaging 2.0 Best effort Reliable messaging Pending

Page

4 References 4.1 Normative NIST FIPS 197. Advanced Encryption Standard (AES). URL http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf. [ETSI TS 102 176-1] Electronic Signatures and Infrastructures (ESI). Algorithms and Parameters for Securie Electronic Signatures. Part 1: hash functions and asymmetric algoritms. URL http://www.etsi.org/ [ISO 15000-2] ISO 15000-2 ebXML Message Service Specification. URL http://www.oasis-open.org/specs/index.php#ebxmlmsgv2 . [PKI-CA] PKI Overheid toegetreden certificatiehouders. URL http://www.pkioverheid.nl/voor-certificaatverleners/toegetredencertificaatverleners/ [PKI-Policy] PKI Overheid Programma van Eisen Deel 2. Toetreden en Toezicht. URL http://www.pkioverheid.nl/voor-certificaatverleners/programma-vaneisen/programma-van-eisen-2005/pve-deel-2/ [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. [RFC 2246] The TLS Protocol. URL http://www.ietf.org/rfc/rfc2246.txt?number=2246 [RFC 2392] Content-ID and Message-ID Uniform Resource Locators URL http://www.ietf.org/rfc/rfc2392.txt [RFC 2437] PKCS #1: RSA Cryptography Specifications. IETF RFC 2437. URL http://www.ietf.org/rfc/rfc2437.txt. [RFC 2822] Internet Message Format. IETF RFC 2822. URL http://www.ietf.org/rfc/rfc2822.txt. [SOAP1.1] Simple Object Access Protocol (SOAP) v1.1. W3C Note 08 May 2000. URL http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ [FIPS 197]

4.2 Non-normative [Deployment Guide 1.1] Pete Wenzel, Jacques Durand. Deployment Profile Template For OASIS ebXML Message Service 2.0. OASIS Committee Draft 1.1, 20 June 2005. URL http://www.oasis-open.org/apps/org/workgroup/ebxmliic/download.php/13750/ebxml-iic-ebms2_deploy_template-spec-cd-11final.doc [ebMS3] OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features URL http://www.oasisopen.org/committees/download.php/21534/ebms_core-3.0-spec-wd16.pdf

[ebBP] [FIPS 180-2] [ISO 15000-1]

[JAB 2.0] [NIST-Keys] [SBG-IBS] [UMMR10]

[UMMUG]

ebXML Business Process Specification Schema Technical Specification URL http://www.oasis-open.org/committees/tc_home.php? wg_abbrev=ebxml-bp#technical. NIST FIPS 180-2 Secure Hash Standard URL http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf ISO 15000-1 ebXML Collaboration Protocol Profile and Agreement Specification. OASIS ebXML Collaboration Protocol Profile and Agreement Specification (2.0). URL http://www.oasis-open.org/committees/ebxmlcppa/documents/ebcpp-2.0.pdf Justitiestandaard Asynchroon Berichtenverkeer 2.0. Technische Specificatie ebXML Configuratiegids. NIST Key Management Guideline. . URL http://csrc.nist.gov/CryptoToolkit/kms/key-management-guideline(workshop).pdf Expertteam Framework Draft Intersectorale Berichtenstandaard. Deel B. Technische Specificatie. Programma Stroomlijnen Basisgegevens. UMM Revision 10. URL http://www.untmg.org/index.php? option=com_docman&task=docclick&Itemid=137&bid=21&limitstart=0&li mit=5. UMM User Guide URL http://www.untmg.org/index.php? option=com_docman&Itemid=137&task=docclick&bid=20&limitstart=0&li mit=5

Overheidsservicebus.nl | Telefoon 070 888 7722

63

OverheidsServiceBus (OSB) OverheidsServiceBus valt onder het programma OverheidsDienstenPlatform (ODP) van ICTU (www.ictu.nl). Binnen het programma OverheidsDienstenPlatform werken wij aan de OverheidsServiceBus (OSB), TerugMeldFaciliteit (TMF) en Gemeenschappelijke Ontsluiting van de Basisregistraties (GOB). Voor meer informatie over het programma: www.overheidsdienstenplatform.nl .

Contactgegevens Telefoon:

070 888 7722

Postadres:

ICTU Postbus 84011 2508 AA Den Haag

Bezoekadres: Beatrixpark Wilhelmina van Pruisenweg 104 2595 AN Den Haag

Overheidsservicebus.nl | Telefoon 070 888 7722

64

OSB Koppelvlakstandaard ebms OSB versie 1.1

Recommend Documents