· Web view- Gateway RM V3 or Gateway RX V3: a product implementing any of these profiles will also be conforming to the AS4 ebHandler CP (the reverse is not true). The AS4 ebHandler

AS4 ProfileFor OASIS ebXML Message Service 3.0

Subcommittee Draft 0.86, [Date TBD]Inline comments <JD> (October November 2426)

Document identifier:[filename TBD]

Location:[link TBD]

Editors:[TBD]

Contributors:[TBD]

Abstract:(Refer to Section Error: Reference source not found, Error: Reference source not found.)

Status:This document is submitted for approval as a committee draft specification.Committee members should send comments on this specification to the [email protected] list. Others should subscribe to and send comments to the [email protected] list. To subscribe, send an email message to [email protected] with the word "subscribe" as the body of the message.For more information about this work, including any errata and related efforts by this committee, please refer to our home page at http://www.oasis-open.org/committees/ebxml-iic.

ebxml-iic-ebms2_deploy_template-spec-cd-11 20 June 2005Copyright © OASIS Open 2005. All Rights Reserved. Page 1 of 37

1

2

3

4

5

67

89

1011

1213

1415

16171819202122232425

12

http://www.oasis-open.org/committees/ebxml-iic

mailto:[email protected]?body=subscribe

mailto:[email protected]



Table of Contents1 Introduction............................................................................................................................ 4

2.1 The AS4 ebHandler Conformance Profile......................................................................52.1.1 Feature Set................................................................................................................52.1.2 WS-I Conformance Requirements.............................................................................72.1.3 Processing Mode Parameters...................................................................................7

2.2 The AS4 light Client Conformance Profile.....................................................................92.2.1 Feature Set................................................................................................................92.2.2 WS-I Conformance Requirements...........................................................................11

2.3 Conformance Profiles Compatibility.............................................................................113 AS4 Additional Features.......................................................................................................11

3.1 Compression...............................................................................................................113.2 Message Replay and Duplicate Detection...................................................................12

4 AS4 Deployment Profile of ebMS 3.0...................................................................................134.1 Core Components/Modules.........................................................................................134.2 Component/Module: Messaging Model.......................................................................15

4.2.1 Profile Requirement Item: Message Exchange Patterns (MEP) and Receipts........154.3 Component/Module: Processing Modes (put at the end).............................................16

4.3.1 Profile Requirement Item: P-Mode Parameters.......................................................164.4 Component/Module: Message Packaging...................................................................17

4.4.1 Profile Requirement Item: Example Item #1............................................................174.5 Component/Module: Error Handling............................................................................17

4.5.1 Profile Requirement Item: Delivery Aware Errors....................................................174.6 Module: Security..........................................................................................................18

4.6.1 Profile Requirement Item: Security Element............................................................184.6.2 Profile Requirement Item: Signing Messages..........................................................184.6.3 Profile Requirement Item: Signing SOAP with Attachments Messages..................194.6.4 Profile Requirement Item: Encrypting Messages.....................................................204.6.5 Profile Requirement Item: Encrypting SOAP with Attachments Messages..............204.6.6 Profile Requirement Item: Security Token Authentication.......................................214.6.7 Profile Requirement Item: Message Authorization..................................................214.6.8 Profile Requirement Item: Securing the PullRequest..............................................224.6.9 Profile Requirement Item: Persistent Signed Receipt..............................................224.6.10 Profile Requirement Item: Persistent Authorization.............................................23

4.7 SOAP Extensions........................................................................................................234.7.1 Profile Requirement Item: #wildCard, Id..................................................................23

4.8 MIME Header Container..............................................................................................244.8.1 Profile Requirement Item: charset...........................................................................24

4.9 HTTP Binding..............................................................................................................244.9.1 Profile Requirement Item: HTTP Headers...............................................................244.9.2 Profile Requirement Item: HTTP Response Codes.................................................254.9.3 Profile Requirement Item: HTTP Access Control....................................................254.9.4 Profile Requirement Item: HTTP Confidentiality and Security.................................26


26

272829303132333435363738394041424344454647484950515253545556575859606162636465666768

34

4.10 Operational Profile.......................................................................................................284.10.1 Deployment and Processing requirements for CPAs..........................................284.10.2 Security Profile....................................................................................................284.10.3 Error Handling Profile..........................................................................................294.10.4 Message Payload and Flow Profile.....................................................................294.10.5 Additional Messaging Features beyond ebMS Specification...............................304.10.6 Additional Deployment or Operational Requirements.........................................30

5 References........................................................................................................................... 315.1 Normative....................................................................................................................315.2 Non-normative.............................................................................................................31

Appendix A. Acknowledgments...............................................................................................32Appendix B................................................................................................................................... 33Appendix C. Revision History..................................................................................................34Appendix D. Notices................................................................................................................35


6970717273747576777879808182

8384

858687888990

56

1 IntroductionThe AS4 profile of the ebMS V3 OASIS standard is intended to achieve the same functionality as AS2, while leveraging the features of the recent ebMS V3 standard. The main features of interest are compatibility with Web services standards, message pulling capability, and a built-in Receipt mechanism.

Profiling ebMS V3 means:- defining of a subset of ebMS V3 options to be supported by the AS4 handler,- deciding which types of message exchanges must be supported, and how these

exchanges should be conducted (level of security, binding to HTTP, etc.) - deciding of AS4-specific message contents and practices (how to make use of the ebMS

message header fields, in an AS4 context).- deciding of some operational best practices, for the end-user.

The overall goal of a profile for a standard is to ensure interoperability by:- Establishing particular usage and practices of the standard within a community of users, - Defining the subset of features in this standard that needs to be supported by an

implementation.

Two kinds of profiles are usually to be considered when profiling an existing standard:

1. Conformance Profiles. These define the different ways a product can conform to a standard, based on specific ways to use this standard. A conformance profile is usually associated with a specific conformance clause. Conformance profiles are of prime interest for product managers and developers: they define a precise subset of features to be supported.

2. Deployment Profiles. These define how a standard should be used by a community of users, in order to ensure best compatibility with business practices and interoperability. Deployment profiles are of prime interest for IT end-users: they define how to configure the use of a standard (and related product) as well as how to bind this standard to business applications. A deployment profile usually points at required or compatible conformance profile(s).

AS4 is defined as a combination of:- An AS4 Conformance Profile (see section …), that defines the subset of ebMS

V3 features to be supported by an AS4 implementation.- An AS4 Deployment Profile (section …) that defines how to use underlying ebMS

V3 features to achieve similar functions as specified in AS2.

2 AS4 Conformance Profiles for ebMS V3

Two AS4 conformance profiles are defined below: (1) the AS4 ebHandler CP. This conformance profile supports both Sending and Receiving

roles, and for each role both message pushing and message pulling.

9192939495

96979899

100101102103

104105106107108

109110

111112113114115116117118119120121122

123124125126127128

129130

131132133134

7

(2) the AS4 light Client CP. This conformance profile supports both Sending and receiving roles, but only message pushing for Sending and message pulling for Receiving. In other words, it does not support incoming HTTP requests, and may have no IP address.

Compatible existing conformance profiles for ebMS V3 are:- Gateway RM V3 or Gateway RX V3: a product implementing any of these profiles will also be conforming to the AS4 ebHandler CP (the reverse is not true).

2.1 The AS4 ebHandler Conformance ProfileThe AS4 ebHandler is identified by the URI:http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/cprofiles/200809/as4ebhandler

2.1.1 Feature Set

AS4 CP is defined as follows, using the table template and terminology provided in Appendix F (“Conformance”) of the core ebXML Messaging Services V3.0 specification [ebMS3].

Conformance Profile:AS4 ebHandler

Profile summary: <“Sending+Receiving” / “AS4 eb Handler” /Level 1 / HTTP1.1 + SOAP 1.2 + WSS1.1 >

Functional Aspects

Profile Feature Set

ebMS MEP Support for all ebMS simple MEPs, in both Sender or Receiver role:

- One-way / Push,

- One-way / Pull,

Regardless of which MEP is used, the sending of an eb:Receipt message must be supported:

- For the One-way / Push, both “response” and “callback” reply patterns must be supported.

- For the One-way / Pull, the “callback” pattern is the only viable option, and the User message sender MUST be ready to accept an eb:Receipt either piggybacked on a PullRequest, or sent separately. The User message receiver MUST be able to send an eb:Receipt separately from the PullRequest.

Use of the ebbpsig:NonRepudiationInformation element (as defined in [ebBP-SIG]) MUST be supported as content for the eb:Receipt message.

Reliability The use of eb:Receipt messages will provide delivery awareness to the User message sender. The semantics of sending back an eb:Receipt message is: a well-formed ebMS user message has been received and the MSH is taking responsibility for its processing, (no additional application-level delivery semantics, and no payload validation semantics).

135136137

138139140141

142

143144145

146

147

148149150

151

8

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/cprofiles/200809/as4ebhandler

No support for a WS reliable messaging specification is required although that is an option.

Security - Support for username / password token, digital signatures and encryption.- Support for content-only transforms.- Support for security of attachments required.- Support for message authorization at P-Mode level (see 7.10 in [ebMS3])

Authorization of the Pull signal - for a particular MPC - must be supported at minimum. Two authorization options must be supported by an MSH in the Receiving role, and at least one of them in the Sending role:

- Authorization Option 1: Use of the WSS security header targeted to the “ebms” actor, as specified in section 7.10 of ebMS V3, with the wsse:UsernameToken profile. This header may either come in addition to the regular wsse security header (XMLDsig for authentication), or may be the sole wsse header, if the SSL protocol is used. An example of message is given in Appendix …

- Authorization Option 2: Use of a regular wsse security header (XMLDsig for authentication, use of X509), and no additional wsse security header targeted to “ebms”, In that case, the MSH must be able to use the credential present in this security header for Pull authorization, i.e. to associate these with a specific MPC. An example of message is given in Appendix …

NOTE on XMLDsig: XMLDsig allows arbitrary XSLT Transformations when construct-ing the plaintext over which a signature or reference is created. Conforming applica-tions that allow use of XSLT transformations when verifying either signatures or refer-ences are encouraged to maintain lists of “safe” transformations for a given partner, service, action and role combination. Static analysis of XSLT expressions with a hu-man user audit is encouraged for trusting a given expression as “safe”

Support for message au-thorization at P-Mode le-vel (see 7.10 in [ebMS3]) using wsse:UsernameTo-ken profile, in particular authorization of the Pull

9

signal for a particular MPC.

Error generation and reporting

- Capability of the Receiving MSH to report errors from message processing, either as ebMS error messages or as Faults to the Sending MSH. The following modes of reporting to Sending MSH are supported: (a) sending error as a separate request (ErrorHandling.Report.ReceiverErrorsTo=<URL of Sending MSH>), (b) sending error on the back channel of underlying protocol (ErrorHandling.Report.AsResponse="true").

- Capability to report to a third-party address (ErrorHandling.Report.ReceiverErrorsTo=<other address>).

- Capability of Sending MSH to report generated errors as notifications to the message producer (support for Report.ProcessErrorNotifyProducer="true")( e.g. delivery failure).

- Generated errors: All specified errors to be generated when applicable, except for EBMS:0010: On Receiving MSH, no requirement to generate error EBMS:0010 for discrepancies between message header and the following P-Mode features: P-Mode.reliability and P-Mode.security, but requirement to generate such error for other discrepancies.

Message Partition Channels

Support for additional message channels beside the default, so that selective pulling by a partner MSH is possible.

Message packaging

- Support for attachments required.- Support for MessageProperties required.- Support for processing messages that contain both a signal message unit

(eb:SignalMessage) and a user message unit (eb:UserMessage).

Interoperability Parameters

Transport: HTTP 1.1SOAP version: 1.2Reliability Specification: none.Security Specification: WSS1.0 and WSS 1.1. When using the One-way / Pull MEP, the response message must use by default the same WSS version as the request message. Otherwise, the version to be applied to a message is specified in the P-Mode.security

2.1.2 WS-I Conformance RequirementsThe Web-Services Interoperability consortium has defined guidelines for interoperability of SOAP messaging implementations. In order to ensure maximal

152153

154155156

10

interoperability across different SOAP stacks, MIME and HTTP implementations, this conformance profile requires compliance with the following WS-I profiles:

Basic Security Profile (BSP) 1.1 [ WSIBSP11] Attachment Profile (AP) 1.0, [WSIAP10] with regard to the use of MIME and

SwA. Notes: Compliance with AP1.0 would normally require compliance with BP1.1, which in

turn requires the absence of SOAP Envelope in the HTTP response of a One-Way (R2714). However, recent BP versions such as BP1.2 [WSIBP12] override this requirement. Consequently, the AS4 ebHandler conformance profile does not require conformance to these deprecated requirements inherited from BP1.1 (R2714, R1143) regarding the use of HTTP.

The above WS-I profiles must be complied with within the scope of features exhibited by the AS4 ebHandler conformance profile. For example, since only SOAP 1.2 is required by AS4 ebHandler, the requirements from BSP 1.1 that depend on SOAP 1.1 would not apply. Similarly, none of the requirements for DESCRIPTION (WSDL) or REGDATA (UDDI) apply here, as these are not used.

This conformance profile may be refined in a future version to require conformance to the following WS-I profiles, once approved and published by WS-I:

Basic Profile 2.0 (BP2.0)iui

2.1.3 Processing Mode ParametersSummary of P-Mode parameters that must be supported by an implementation conforming to this profile. Fore each parameter, either: full support is required: an implementation is supposed to support the possible options for this

parameter. Support for a subset of values is required. No support is required: an implementation is not required to support the features controlled by

this parameter, and therefore not required to understand this parameter.

0. General PMode parameters: (PMode.ID: support not required) (PMode.Agreement: support not required) PMode.MEP: support for: http://www.oasis-open.org/committees/ebxml-msg/

{one-way, two-way} PMode.MEPbinding: support for:

http://www.oasis-open.org/committees/ebxml-msg/{ push, pull, sync} PMode.Initiator.Party: support required. PMode.Initiator.Role: support required. PMode.Initiator.Authorization.username and

PMode.Initiator.Authorization.password: support for: wsse:UsernameToken. PMode.Responder.Party: support required. PMode.Responder.Role: support required.

157158

159160161162

163164165166167168169170171172173174175

176

177

178179180181182183184185

186187

188189190191192193194195196197198199

11

PMode.Responder.Authorization.username and PMode.Responder.Authorization.password: support for: wsse:UsernameToken.

1. PMode[1].Protocol: PMode[1].Protocol.Address: support for “http” scheme. PMode[1].Protocol.SOAPVersion: support for SOAP 1.2.

2.PMode[1].BusinessInfo: PMode[1].BusinessInfo.Service: support required. PMode[1].BusinessInfo.Action: support required. PMode[1].BusinessInfo.Properties[]: support required. (PMode[1].BusinessInfo.PayloadProfile[]:not required) (PMode[1].BusinessInfo.PayloadProfile.maxSize: not required) PMode[1].BusinessInfo.MPC: support required.

3. PMode[1].ErrorHandling: (PMode[1].ErrorHandling.Report.SenderErrorsTo: support not required) PMode[1].ErrorHandling.Report.ReceiverErrorsTo: support required (for

address of the MSH sending the message in error or for third-party). PMode[1].ErrorHandling.Report.AsResponse: support required (true/false). (PMode[1].ErrorHandling.Report.ProcessErrorNotifyConsumer support not

required) PMode[1].ErrorHandling.Report.ProcessErrorNotifyProducer: support required

(true/false) PMode[1].ErrorHandling.Report.DeliveryFailuresNotifyProducer: support

required (true/false)

4. PMode[1].Reliability:None

5. PMode[1].Security: PMode[1].Security.WSSVersion: support required for: {1.0 , 1.1 } PMode[1].Security.X509.Sign: support required. PMode[1].Security.X509.Signature.Certificate: support required. PMode[1].Security.X509.Signature.HashFunction: support required. PMode[1].Security.X509.Signature.Algorithm: support required. PMode[1].Security. X509.Encryption.Encrypt: support required. PMode[1].Security.X509.Encryption.Certificate: support required. PMode[1].Security.X509.Encryption.Algorithm: support required. (PMode[1].Security.X509.Encryption.MinimumStrength: support not

required)

200201202

203204

205206

207208

209210211212213214215

216

217218219220221222223224225226

227228

229

230231

232233234235236237238239240241

12

PMode[1].Security.UsernameToken.username: support required. PMode[1].Security.UsernameToken.password: support required. PMode[1].Security.UsernameToken.Digest: support required (true/false) (PMode[1].Security.UsernameToken.Nonce: not required) PMode[1].Security.UsernameToken.Created: support required. PMode[1].Security.PModeAuthorize: support required (true/false) PMode[1].Security.SendReceipt: support required (true/false) Pmode[1].Security.SendReceipt.ReplyPattern: support required (both “response” and

“callback”))

2.2 The AS4 light Client Conformance ProfileThe AS4 light Client is identified by the URI:http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/cprofiles/200809/as4ebhandler

2.2.1 Feature SetConformance Profile:LHRM-CP

Profile summary: <“Sending+Receiving” / “ lighthandler-rm” /Level 1 / HTTP1.1 + SOAP 1.1>

Functional Aspects Profile Feature SetebMS MEP Support for One-way / Push (as initiator), and One-way / Pull (as

initiator).Regardless of which MEP is used, the sending of an eb:Receipt message must be supported:

- For the One-way / Push, the “response” reply pattern must be supported.

- For the One-way / Pull, the “callback” pattern is the only viable option, and the User message sender MUST be ready to accept an eb:Receipt either piggybacked on a PullRequest, or sent separately. The User message receiver MUST be able to send an eb:Receipt separately from the PullRequest.

(?) Use of the ebbpsig:NonRepudiationInformation element (as defined in [ebBP-SIG]) MUST be supported as content for the eb:Receipt message.

Reliability The use of eb:Receipt messages will provide delivery awareness to the User message sender. The semantics of sending back an eb:Receipt message is: a well-formed ebMS user message has been received and the MSH is taking responsibility for its processing, (no additional application-level delivery semantics, and no payload validation semantics).

No support for a WS reliable messaging specification is required although that is an option.

Security Both authorization options for message pulling (authorizing PullRequest for a particular MPC) described in the ebHandler conformance profile

242243244245246247248249250

251

252253254

255

256

13

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/cprofiles/200809/as4ebhandler

MUST be supported:

1. Support for username / password token: minimal support for wss:UsernameToken profile in the Pull signal - for authorizing a particular MPC. Support for adding a WSS security header targeted to the “ebms” actor, as specified in section 7.10 of ebMS V3, with the wsse:UsernameToken profile. The use of SSL protocol is recommended.2. Support for a regular wsse security header (XMLDsig for authentication, use of X509), and no additional wsse security header targeted to “ebms”,

Error reporting Support for error notification to the local message producer (e.g. reported failure to deliver pushed messages). Ability to report message processing errors for pulled messages to the remote party via Error messages (such an error may be bundled with another pushed message or a Pull signal.).

Message Partition Channels Sending on default message partition flow channel (no support for additional message partitions required.)

Message packaging No support for attachments required – i.e. the payload will use the SOAP body-, no support for MessageProperties required.

Interop Parameters Transport: HTTP 1.1SOAP version: 1.2WSS:. WSS1.1Reliability Specification: none

2.2.2 WS-I Conformance RequirementsThis conformance profile will require compliance with the following WS-I profile, once formally approved by WS-I (currently in Board approval draft status):

Basic Profile 2.0 [WSIBP20]Note: the above WS-I profile must be complied with within the scope of features exhibited by the AS4 Light Client ebMS conformance profile.

2.3 Conformance Profiles CompatibilityThe AS4 light Client is identified by the URI:

The AS4 profile is compatible with the following ebMS V3 conformance profiles, defined in [ebMS3-CP]:

Gateway RM V2/3 Gateway RM V3 Gateway RX V2/3 Gateway RX V3

257

258259260261262263

264265

266267

268269270

271272273274

14

AS4 may be deployed on any MSH that conforms to one of the above conformance profiles.

3 AS4 Deployment Profile of ebMS 3.0Additional Features

This section defines features that were not specified in ebMS V3 and therefore out of scope for the previous conformance profiles (ebHandler CP and Light Client CP). These features should be considered as additional capabilities that are either required by or made optional to AS4 implementations.

The profiling tables below can be used for adding user-defined profiling requirements to be adopted within a business community. Whenever the feature – or its profiling - is mandatory, the right-side column (Profile Requirement) will specify it,

3.1 Compression

Application payloads that are built in conformance with the SOAP Messages with Attachments [SOAPATTACH] specification may be compressed. Compression of the SOAP envelope and/or payload containers within the SOAP Body of an ebMS Message is not supported.

To compress the payload(s) of a message build in conformance with the SOAP Messages with Attachments [SOAPATTACH] specification the GZIP compression algorithm MUST be used. Compression MUST be applied before payloads are attached to the SOAP Message. The content type of the compressed attachment MUST be "application/gzip".

When compression, signature and encryption are required of the MSH, the message MUST be compressed prior to being signed and/or encrypted.

Packaging requirements:

A eb:PartInfo/eb:PartProperties/eb:Property/@name="MimeType" value is RECOMMENDED to identify the mimetype of the payload before compression was applied.

A eb:PartInfo/eb:PartProperties/eb:Property/@name="CharacterSet" value is RECOMMENDED to identify the character set of the payload before compression was applied.

Example: <eb:PartInfo href="[email protected]" <mailto:[email protected]> > <eb:PartProperties> <eb:Property name="MimeType">application/xml</eb:Property> <eb:Property name="CharacterSet">utf-8</eb:Property>

275276

277

278

279280281282283

284285286287288

289

290291292293294295296297298299300301

303304305306307308309310311312313314315

15

mailto:cid%[email protected]

</eb:PartProperties> <eb:PartInfo>

An additional PMode parameter is defined:

PMode[1].PayloadService.Compression: {true / false} True: some attached payload(s) may be compressed over this MEP segment.False (default): no compression is used over this MEP segment.

3.2 Message Replay and Duplicate Detection

These capabilities are making use of the eb:Receipt as the sole type of acknowledgement that must be supported. Duplicate detection only relies on the eb:MessageInfo/eb:MessageId.

Message Replay and Duplicate Detection Profile requirements

If delivery awareness is required, what is the expected behavior if no Receipt message is received by the User message sender? (a) Simply escalate receipt failure to the provider application. No message replay(b) A User message sender that has not received an expected eb:Receipt MAY resend the User message. If doing so, the eb:MessageInfo/eb:MessageId element of the resend message and of the original User message MUST be same. However, the eb:MessageInfo/eb:Timestamp MUST be different. If no receipt is obtained, escalate failure to the provider application.

(optional)

If delivery awareness is required, what is the expected capability of the Receiver?(a) Nothing more than sending an eb:Receipt.(b) In addition to (a), a User message receiver MAY detect and/or eliminate duplicates based on eb:MessageInfo/eb:MessageId.

(optional)

Others

316317318319

320321322323

324325

326

327328329

330

331332

16

4 AS4 Deployment Profile of ebMS 3.0

This section summarizes the which components and modules of the ebMS 3.0 Core Features 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 component/module, this section also specifies whether the component/module has been profiled or not. If yes, the profiling details are given in following section(s).

Sections beyond 4.1 give more details about the profiling of specific modules. The profile requirement tables leave room for additional conventions that users may define and use within a business community.

4.1 Core Components/ModulesComponent Name and Reference

Messaging Model (section 2)

Profiling Status

Usage: RequiredProfiled: Yes

Notes This Profile only supports the One-Way/Push MEP (Sync and Async) and the One-Way/Pull MEP.

Component Name and Reference

Message Pulling and Partitioning (section 3)

Profiling Status

Usage: RequiredProfiled: No

Notes This Profile supports Message Pulling and MPCs without any profiling points.


Processing Modes (section 4)

Profiling Status


Notes

Component Name and

Message Packaging (section 5)

333

334335336337338339340341

342343344345

346

347

348

349

17

Reference

Profiling Status


Notes Default business process that defines acceptable defaults for Role, Service, and ActionSubcommittee is considering not supporting Bundled Messages (piggybacking) for the One-Way/Pull MEP.


Error Handling (section 6)

Profiling Status


Notes Possible addition of some new Error Codes regarding Delivery Awareness

Module Name and Reference

Security Module (section 7)

Profiling Status


Notes Guidance to be specified regarding which part(s) of the message to be encrypted and included in the signature. Further guidance to be specified on how to securitize the PullRequest Signal and the preventing of replay attacks since the Reliable Message module will not be used.

Module Name and Reference

Reliable Messaging Module (section 8)

Profiling Status

Usage: Not supported by this profileProfiled: No

Notes This profile does not support the use of the Reliable Messaging Module using either WS-ReliableMessaging or WS-Reliability. It furthermore supports a lighter version of RM called “Delivery Awareness”.

4.2 Component/Module: Messaging Model

350

351

352

353354

355

356

18

4.2.1 Profile Requirement Item: Message Exchange Patterns (MEP) and Receipts

Scope of the Profile Feature

Defines usage of ebMS MEPs, including Receipts.

Specification Feature

Specification Reference

ebMS v3.0, Section 2.2

Profiling (a) This profile supports the One-Way/Push MEP. Both synchronous and asynchronous transport channels for the response (eb:Receipt) are supported by this profile. and Callback)The Receiving MSH SHALL return the eb:Receipt,

(1) either on the HTTP response (back-channel). (Pmode[1].Security.SendReceipt.ReplyPattern value = ‘Response’or using a separate connection. (Pmode[1].Security.SendReceipt.ReplyPattern value = ‘Callback’.

Profiling (b) This profile supports the One-Way/Pull MEP. The Receiving MSH SHALL return the eb:Receipt using a separate connection. Message bundling of eb:Receipts and PullRequests are not supported by this profile.

Test References

Notes Do we need to include the data flow diagrams that Jacques built?<JD> this can be useful.

4.3 Component/Module: Processing Modes (put at the end)

4.3.1 Profile Requirement Item: P-Mode ParametersSpecification Feature


ebMS 3.0, Appendix D.3

Profiling (a) PMode.MEP parameter will be constrained to the following value:http://docs..oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/oneWay

Profiling (b) PMode.MEPbinding parameter will be constrained to the following values:http://docs..oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/pushhttp://docs..oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/pull

Profiling (c) PMode.Initiator.Role parameter will have the following default value:

357358

359

360

361

19

http://docs..oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/initiator

Profiling (d) PMode.Responder.Role parameter will have the following default value:http://docs..oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/responder

Profiling (e) PMode.Initiator.Role parameter will have the following default value:

Profiling (e) PMode[1].BusinessInfo.Service parameter will have the following default value:http://docs..oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200810/AS4/serviceNOTE: this default is to be considered a PMode content default: absence of the PMode itself will cause the default value defined in the ebMS V3 specification (section 4.3) to apply. This value is usually enforced by the MSH implementation itself.

Profiling (f) PMode[1].BusinessInfo.Action parameter will have the following default value:http://docs..oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200810/AS4/actionNOTE: this default is to be considered a PMode content default: absence of the PMode itself will cause the default value defined in the ebMS V3 specification (section 4.3) to apply. This value is usually enforced by the MSH implementation itself

Profiling (gh) PMode[1].Reliability parameters are not supported by this profile

Alignment

Test References

Notes

4.4 Component/Module: Message Packaging

4.4.1 Profile Requirement Item: Example Item #1Specification Feature


Profiling (a)

Profiling (b)

362

363

364

20

Profiling (c)

Alignment

Test References

Notes

4.5 Component/Module: Error Handling

4.5.1 Profile Requirement Item: Delivery Aware ErrorsSpecification Feature


N/A

Profiling (a) All error reporting options are left for users to agree on, including the choice to not report at all: PMode[1].ErrorHandling.Report.ReceiverErrorsTo: are such er-rors always supposed to be sent back to the Sender?PMode[1].ErrorHandling.Report.AsResponse : should it be always « true » for one-way messages that have errors ?

Profiling (b) Is there any specific AS4 error to be supported besides EBMS:xxxx errors? (as the term “Delivery Aware” suggests)? E.g. if a Receipt could not be generated for some other reason than regular message processing errors? Or if a n AS4 handler has not received an expected Receipt (error for its Producer app)?

Profiling (c)

Alignment

Test References

Notes New Error Code(s) for Delivery Aware Errors TBD

4.6 Module: Security

4.6.1 Profile Requirement Item: Security ElementSpecification Feature

365

366

367

368

369

21



Profiling (a) An AS4 MSH implementation is REQUIRED to use the Web Services Security X.509 Certificate Token Profile [WSS10-X509] or [WSS11-X509].

Alignment [WSS11] Anthony Nadalin, et al, eds., Web Services Security: SOAP Message Security 1.1, 2005. <http://docs.oasis-open.org/wss/v1.1/> [WSS11-X509] A. Nadalin, et al, eds., Web Services Security X.509 Certificate Token Profile 1.1, 2006.

Test References

Notes

4.6.2 Profile Requirement Item: Signing MessagesSpecification Feature



Profiling (a) AS4 MSH implementations are REQUIRED to use Detached Signatures as defined by the XML Signature Specification [XMLDSIG] when signing AS4 user or signal messages. Enveloped Signatures as defined by [XMLDSIG] are not supported by (<JD>or authorized in) this profile.

Profiling (b) AS4 MSH implementations are REQUIRED to include the entire eb:Messaging SOAP header block and the SOAP Body in the signature.

Alignment

Test References

Notes

4.6.3 Profile Requirement Item: Signing SOAP with Attachments Messages


370

371372

22



Profiling (a) AS4 MSH implementations are REQUIRED to use the Attachment-Content-Only transform when building application payloads using SOAP with Attachments [SOAPATTACH]. The Attachment-Complete transform is not supported by this profile.

Profiling (b) AS4 MSH implementations are REQUIRED to include the entire eb:MessagingContainer Element <JD>???header block and all MIME body parts of included payloads in the signature.

Alignment

Test References

Notes

4.6.4 Profile Requirement Item: Encrypting MessagesSpecification Feature



Profiling (a) AS4 MSH implementations are SHALL NOT encrypt the eb:PartyInfo section of the eb:Messaging header. Other child elements of the eb:Messaging header MAY be encrypted or left unencrypted as defined by trading partner agreements or collaboration profiles.

Profiling (b) If an AS4 user message is to be encrypted and the user-specified payload data is to be packaged in the SOAP Body, AS4 MSH implementations are REQUIRED to encrypt the SOAP Body.

Alignment

Test References

Notes

373

23

4.6.5 Profile Requirement Item: Encrypting SOAP with Attachments Messages




Profiling (a) If an AS4 user message is to be encrypted and the user-specified payload data is to be packaged in conformance with the [SOAPATTACH] specification, AS4 MSH implementations are REQUIRED to encrypt the MIME Body parts of included payloads.

Alignment

Test References

Notes

4.6.6 Profile Requirement Item: Security Token AuthenticationSpecification Feature



Profiling (a)

Alignment

Test References

Notes

4.6.7 Profile Requirement Item: Message AuthorizationSpecification Feature

PullRequest message authorization (for pulling over a particular MPC).NOTE: both options below (a) and (b) are supported by a Receiving MSH. At

374375

376

377

24

least one of them MUST be supported by a Sending MSH. This must be agreed in the partner agreement.



Profiling option (a) PullRequest is authorized based on wsse:UsernameToken in the wsse Se-

curity header targeted to “ebms”.

Note that this authorization requires a second wsse header from the one in 2.5.8. , unless transient security is used (SSL).

Profiling option (b)

PullRequest is authorized based on a regular Security header, using X509 cer-tificates. In that case, the second security header (targeted to “ebms”) is not necessary.

Alignment [WSS11-USER] A. Nadalin, et al, eds., Web Services Security UsernameToken Profile 1.1, 2006. <http://docs.oasis-open.org/wss/v1.1/>

Test References

Notes

4.6.8 Profile Requirement Item: Securing the PullRequestSpecification Feature


ebMS v3.0, Section 7.11.x

Profiling (a) An AS4 Sending MSH MUST authenticate a Receiving MSH that sends a PullRequest by using [WSS10-X509] or [WSS11-X509] coupled with the Message Partition Channel that a Pull signal is accessing for pulling messages.

Profiling (b) For trading communities that are concerned about the possible malignant capture and replay attack of a PullRequest, it is RECOMMENDED that trading PullRequest signals be sent using the HTTPS transport protocol with optional Client-side Authentication.

Alignment

378

25

Test References

Notes

4.6.9 Profile Requirement Item: Persistent Signed ReceiptSpecification Feature


ebMS v3.0, Section 7.12..2

Profiling (a) An AS4 message that has been digitally signed MUST be acknowledged with a message containing an eb:Receipt signal that itself is digitally signed. The eb:Receipt MUST contain the information necessary to provide nonrepudiation of reciept of the original message.

Alignment

Test References

Notes

4.6.10 Profile Requirement Item: Persistent AuthorizationSpecification Feature


ebMS v3.0, Section 7.12..7

Profiling (a) (user discretion)

Alignment

Test References

Notes

379

380

26

4.7 SOAP Extensions

4.7.1 Profile Requirement Item: #wildCard, IdSpecification Feature

Header elements:


ebMS 2, section 2.3.6, 2.3.7, 2.3.8

Profiling (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 alone in a digital signature?(Section 2.3.8) Is a version other than "2.0" allowed or required for any extension elements?

Alignment

Test References

Notes

4.8 MIME Header Container

4.8.1 Profile Requirement Item: charsetSpecification Feature

MIME Header elements:Content-Type


ebMS 2, section 2.1.3.2

Profiling 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"

Alignment

Test References

381

382

383

384

385

386

27

Notes

4.9 HTTP Binding

4.9.1 Profile Requirement Item: HTTP HeadersSpecification Feature

Header elements, MIME parts


Profiling (a) Is a (non-identity) content-transfer-encoding required for any of the MIME multipart entities?

Profiling (b) If other than "ebXML" what must the SOAPAction HTTP header field contain?

Profiling (c) What additional MIME-like headers must be included among the HTTP headers?

Alignment

Test References

Notes

4.9.2 Profile Requirement Item: HTTP Response CodesSpecification Feature



ebMS 2, Appendix B.2.3.

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

Alignment

Test

387

388

389

390

391

28

References

Notes

4.9.3 Profile Requirement Item: HTTP Access ControlSpecification Feature




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

Alignment Appears as AccessAuthentication elements in CPA.]

Test References

Notes

4.9.4 Profile Requirement Item: HTTP Confidentiality and SecuritySpecification Feature




Profiling (a) Is HTTP transport-layer encryption required?What protocol version(s)? [SSLv3, TLSv1, for example. Refer to item 4.1.4.6 in Security section.]

Profiling (b) What encryption algorithm(s) and minimum key lengths are required?

Profiling (c) What Certificate Authorities are acceptable for server certificate authentication?

Profiling (d) Are direct-trust (self-signed) server certificates allowed?

Profiling (e) Is client-side certificate-based authentication allowed or required?

392

393

394

395

29

Profiling (f) What client Certificate Authorities are acceptable?

Profiling (g) What certificate verification policies and procedures must be followed?

Alignment

Test References

Notes

4.10 Additional Features

4.11

4.12These features represent capabilities beyond what the AS4 conformance profile for ebMS V3 (defined in Section 2) is requiring, as they are not specified in the ebMS V3 standard.

4.13Compression

4.14Message Compression 4.15Profile requirements

4.16Which method is used?

4.17Guidance for compressing business payloads and how compressed payloads are packaged with respect to the Security Module will be described by its own Conformance Profile document

4.18<JD> need be more specific here?

How is compression indicated in the message? In the PMode?

396

397

398

399400401

402

30

Others

4.18.1 Message Replay and Duplicate DetectionMessage Replay and Duplicate Detection Profile requirements

If delivery awareness is required, what is the expected behavior if no Receipt message is received by the User message sender? (a) Simply escalate receipt failure to the provider application. No message replay(b) A User message sender that has not received an expected eb:Receipt MAY resend the User message. If doing so, the eb:MessageInfo/eb:MessageId element of the resend message and of the original User message MUST be same. However, the eb:MessageInfo/eb:Timestamp MUST be different. If no receipt is obtained, escalate failure to the provider application.

If delivery awareness is required, what is the expected capability of the Receiver?(a) Nothing more than sending an eb:Receipt.(b) In addition to (a), a User message receiver MAY detect and/or eliminate duplicates based on eb:MessageInfo/eb:MessageId.

Others

403404

405

406407

31

4.19Operational ProfileThis section defines the operational aspect of the profile: type of deployment that the above profile is supposed to be operated with, expected or required conditions of operations, usage context, etc.

4.19.1 Deployment and Processing requirements for CPAsCPA Access Profile requirements

Is a specific registry for storing CPAs required? If so, provide details.

(user discretion)

Is there a set of predefined CPA templates that can be used to create given Parties’ CPAs?

(user discretion)

Is there a particular format for file names of CPAs, in case that file name is different from CPAId value?

(user discretion)

Others

4.19.2 Security ProfileSecurity Profile Profile requirements

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, isTamperproof, isAuthenticated definitions.]

Example - within EAN•UCC, it is recommended to adopt persistent security at the application level, including:• Persistent digital signature• Persistent signed receipt• Persistent confidentiality• Persistent authorization[This corresponds to Security Profile 21.]

(section 4.1.5) Are any recommendations given, with respect to protection or proper handling of MIME headers within an ebXML Message?

(user discretion)

Are any specific third-party security packages approved or required?

(user discretion)

What security and management policies and practices are recommended?

(user discretion)

408

409410411412

413

414

415

416

32

Any particular procedure for doing HTTP authentication, e.g. if exchanging name and password, how?

Others

4.19.3 Error Handling ProfileError Reporting Profile requirements

(Section 4.2.4.2) Should errors be reported to a URI that is different from that identified within the From element? What are the requirements for the error reporting URI and the policy for defining it?

<JD> AS4 may have some further requirements here.(user discretion)

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?

(user discretion)<JD> AS4 may have some further requirements here.

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

(user discretion)<JD> AS4 may have some further requirements here.

Others

4.19.4 Message Payload and Flow ProfileMessage Quantitative Aspects Profile requirements

What are typical and maximum message payload sizes that must be handled? (maximum, average)

(user discretion)

What are typical communication bandwidth and processing capabilities of an MSH for these Services?

(user discretion)

Expected Volume of Message flow (throughput): maximum (peak), average?

(user discretion)

(Section 2.1.4) How many Payload Containers must be present?

(user discretion)

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

(user discretion)

417

418

419

420

33

allowed for attachments?

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?

(user discretion)

Others

4.19.5 Additional Messaging Features beyond ebMS Specification

Additional Features Profile requirements

Are there additional features out of specification scope, that are part of this messaging profile, as an extension to the ebMS profiling?

(user discretion)

4.19.6 Additional Deployment or Operational RequirementsOperational or Deployment Conditions Profile requirements

Operational or deployment aspects that are object to further requirements or recommendations.

Recommended or required practices.

421

422423

424

425

426

34

5 References5.1 Normative

[ebMS] OASIS, ebXML Message Service Specification Version 2.0, http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0.pdf, April 1, 2002.

[ebMS3] OASIS ebXML Messaging Services, Version 3.0: Part 1, Core Features, 2007. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.pdf

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

[WSIBP20] WS-I Basic Profile V2.0 (draft), Web-Services Interoperability Consortium, 2008. http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile

[WSIBSP11] Abbie Barbir, et al, eds, Basic Security Profile Version 1.1, Web-Services Interoperability Consortium, 2006. http://www.wsi.org/Profiles/BasicSecurityProfile-1.1.html

[ebBP-SIG] OASIS ebXML Business Process TC, ebXML Business Signals Schema, 2006.<http://docs.oasis-open.org/ebxml-bp/ebbp-signals-2.0>

[WSS11] Anthony Nadalin, et al, eds., Web Services Security: SOAP Message Security 1.1, 468 2005. http://docs.oasis-open.org/wss/v1.1/

[WSIAP10] WS-I Attachment Profile V1.0, Web-Services Interoperability Consortium, 2007. http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile

5.2 Non-normative[ebCPPA] OASIS, Collaboration-Protocol Profile and Agreement Specification

Version 2.0, http://www.oasis-open.org/committees/ebxml-cppa/documents/ebCPP-2_0.pdf, September 23, 2002.

[ebDGT] OASIS, ebXML Deployment Guide Template Specification Version 1.0 (ebXML IIC) http://www.oasis-open.org/apps/org/workgroup/ebxml-iic/download.php/1713/ebMS_Deployment_Guide_Template_10.doc, April 7, 2003.

[BPSS] ebXML, ebXML Business Process Specification Schema Version 1.0.1, http://www.ebxml.org/specs/ebBPSS.pdf, May 11, 2001.

427

428429430431432433434435436437438439440441442443444445

446447448

449450

451452453454

455456

457458459460461462463464465

466467468

35

http://www.oasis-open.org/committees/ebxml-cppa/documents/ebCPP-2_0.pdf

http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile


http://docs.oasis-open.org/wss/v1.1/

http://www.wsi.org/Profiles/BasicSecurityProfile-1.1.html

http://www.wsi.org/Profiles/BasicSecurityProfile-1.1.html



http://www.ietf.org/rfc/rfc2119.txt

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.pdf

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.pdf

http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0.pdf

http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0.pdf

[ebMS3-CP] OASIS, ebXML Message Service Version 3.0 Conformance Profiles, http://www.oasis-open.org/committees/download.php/24829/ebms-3.0-confprof-cd-02.pdf, July 25, 2007

469470471472

36

Appendix A. AcknowledgmentsIn addition to editors or direct contributors, the following individuals were members of the committee during the development of this specification or of a previous version of it:

Mike Dillon, Drummond Group Inc. <[email protected]>Jacques Durand, Fujitsu <[email protected]>Dale Moberg, Axway <[email protected]>

473

474475476477478

37




Appendix B.479

38

Appendix C. Revision HistoryRev Date By Whom What

0.1 26 June, 2002 P. Wenzel Initial draft.

0.2 16 September, 2002 P. Wenzel Reformatted document, published with notes by J. Durand.

0.3 3 October, 2002 P. Wenzel Rearranged into user-targeted sections, incorporated comments by J. Durand, M. Martin, E. van LydeGraf.

1.0 27 January, 2003 P. Wenzel Additional text, cleanup and CPA references by P. Wenzel; non-normative EAN•UCC examples by T.Bikeev; comments by J. Durand.

1.0 24 February, 2003 P. Wenzel Incorporated comments by J. Durand.

1.0 26 February, 2003 P. Wenzel Incorporated comments by M. MacKenzie.

1.0 28 March, 2003 P. Wenzel Applied OASIS document formatting guidelines.

1.1 28 JuneOctober, 20085 J. Durand Recast the previous document in new Deployment Template format, plus some editorial correctionsComplete draft.

480

481

39

Appendix D. NoticesOASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the OASIS Executive Director.OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.Copyright © OASIS Open 2005. All Rights Reserved.This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

482

483484485486487488489490491492493494495496497498499500501502503504505506507508509510511

40

· Web view- Gateway RM V3 or Gateway RX V3: a product implementing any of these profiles will also be conforming to the AS4 ebHandler CP (the reverse is not true). The AS4 ebHandler

Documents