Deployment Profile Template v1.1

For OASIS ebXML Message Service 2.0 Standard

Public Review Draft 01, 04 December 2006

Artifact identifier:

ebXML_DPT-v1.1-ebMS2-template-pr-01

Location:

http://www.oasis-open.org/committees/documents.php?wg_abbrev=ebxml-iic

Artifact Type:

template

Technical Committee:

OASIS ebXML Implementation, Interoperability and Conformance (IIC) TC

Chair:

Jacques Durand, Fujitsu <jdurand@us.fujitsu.com>

Editors:

Pete Wenzel, SeeBeyond <pete@seebeyond.com>

Jacques Durand, Fujitsu <jdurand@us.fujitsu.com>

Contributors:

Sacha Schlegel, CycloneCommerce <sschlegel@cyclonecommerce.com>

Pim van der Eijk, OASIS Europe <pim.vandereijk@oasis-open.org>

Monica Martin, Sun Microsystems <Monica.Martin@sun.com>

SHIMAMURA Masayoshi, Fujitsu Limited <shima.masa@jp.fujitsu.com>

Thomas Bikeev, EAN International <bikeev@ean-int.org>

Abstract:

(Refer to Section 1.1, Purpose.)

Status:

This document was last revised or approved by the OASIS ebXML IIC TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/ebxml-iic.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/ebxml-iic/ipr.php).

 

Notices

OASIS 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 may 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.

 


Table of Contents

1      Introduction. 5

1.1 Purpose. 5

1.2 Terminology. 5

1.3 How to Use the Deployment Profile Template. 6

2      Profiling the Modules of ebMS 2.0. 8

2.1 Core Modules. 8

2.2 Additional Modules. 8

2.3 Communication Protocol Bindings. 10

2.3.1 Profile Requirement Item: Transport Protocol 10

3      Profile Requirements Details. 11

3.1 Module: Core Extension Elements. 11

3.1.1 Profile Requirement Item: PartyId. 11

3.1.2 Profile Requirement Item: Role. 11

3.1.3 Profile Requirement Item: CPAId. 12

3.1.4 Profile Requirement Item: ConversationId. 12

3.1.5 Profile Requirement Item: MessageId. 13

3.1.6 Profile Requirement Item: Service. 14

3.1.7 Profile Requirement Item: Action. 14

3.1.8 Profile Requirement Item: Timestamp. 15

3.1.9 Profile Requirement Item: Description. 15

3.1.10 Profile Requirement Item: Manifest 16

3.1.11 Profile Requirement Item: Reference. 16

3.1.12 Profile Requirement Item: Reference/Schema. 17

3.1.13 Profile Requirement Item: Reference/Description. 17

3.2 Module: Security. 18

3.2.1 Profile Requirement Item: Signature generation. 18

3.2.2 Profile Requirement Item: Persistent Signed Receipt 19

3.2.3 Profile Requirement Item: Non Persistent Authentication. 19

3.2.4 Profile Requirement Item: Non Persistent Integrity. 20

3.2.5 Profile Requirement Item: Persistent Confidentiality. 20

3.2.6 Profile Requirement Item: Non Persistent Confidentiality. 21

3.2.7 Profile Requirement Item: Persistent Authorization. 21

3.2.8 Profile Requirement Item: Non Persistent Authorization. 22

3.2.9 Profile Requirement Item: Trusted Timestamp. 22

3.3 Module : Error Handling. 23

3.3.1 Profile Requirement Item: 23

3.4 Module : SyncReply. 24

3.4.1 Profile Requirement Item: SyncReply. 24

3.5 Module : Reliable Messaging. 24

3.5.1 Profile Requirement Item: SOAP Actor attribute. 24

3.5.2 Profile Requirement Item: Signed attribute. 25

3.5.3 Profile Requirement Item: DuplicateElimination. 25

3.5.4 Profile Requirement Item: Retries and RetryInterval 26

3.5.5 Profile Requirement Item: PersistDuration. 26

3.5.6 Profile Requirement Item: Reliability Protocol 27

3.6 Module : Message Status. 28

3.6.1 Profile Requirement Item: Status Request message. 28

3.6.2 Profile Requirement Item: Status Response message. 28

3.7 Module : Ping Service. 29

3.7.1 Profile Requirement Item: Ping-Pong Security. 29

3.8 Module : Multi-Hop. 29

3.8.1 Profile Requirement Item: Use of intermediaries. 29

3.8.2 Profile Requirement Item: Acknowledgements. 30

3.9 SOAP Extensions. 30

3.9.1 Profile Requirement Item: #wildCard, Id. 30

3.10 MIME Header Container 31

3.10.1 Profile Requirement Item: charset 31

3.11 HTTP Binding. 32

3.11.1 Profile Requirement Item: HTTP Headers. 32

3.11.2 Profile Requirement Item: HTTP Response Codes. 32

3.11.3 Profile Requirement Item: HTTP Access Control 33

3.11.4 Profile Requirement Item: HTTP Confidentiality and Security. 33

3.12 SMTP Binding. 34

3.12.1 Profile Requirement Item: MIME Headers. 34

3.12.2 Profile Requirement Item: SMTP Confidentiality and Security. 34

4      Operational Profile. 36

4.1 Deployment and Processing requirements for CPAs. 36

4.2 Security Profile. 36

4.3 Reliability Profile. 37

4.4 Error Handling Profile. 37

4.5 Message Payload and Flow Profile. 37

4.6 Additional Messaging Features beyond ebMS Specification. 38

4.7 Additional Deployment or Operational Requirements. 38

5      References. 39

5.1 Normative. 39

5.2 Non-Normative. 39

Appendix A. Acknowledgments. 40

Appendix B. Revision History. 41

 

1           Introduction

1.1 Purpose

The ebXML Message Service Specification 2.0 [ebMS] contains several configurable features and options.  Any use of ebMS requires a certain amount of standardization within a trading community. Due to the degree of optionality allowed by the specification, these communities will want to document exactly which parts of it must be deployed and how, in order to foster interoperability on multiple levels between participants. Also, a community may want to further profile the content and format of some message elements, to match their business practices.

 

Such information may be collected and published as a Deployment Guide for a community.  It also represents an agreed-upon convention for the use of the ebXML message handler within the community, the capabilities that are expected from an implementation, and the deployment details.  This is not to be confused with the notion of Collaboration Protocol Agreement [ebCPPA] (CPA), which focuses on the runtime collaboration mode between partners, for a particular business process.  Some elements of the Deployment Template will, however, map to a community’s specific requirements of applicable CPA elements.

 

This Deployment Profile Template for ebMS 2.0 is intended to be filled or instantiated by one or more user communities. Once instantiated and optionally extended with material that is specific to this community, it becomes a Deployment Profile, or Guide.  It is the intention of the OASIS ebXML IIC Technical Committee to collect and archive examples of Deployment Profiles created from this Template, as an aid to user communities whose standardization efforts involve the ebXML Message Service.

 

By publishing Deployment Profiles for different communities using the same Template format, it will be easier for a user community to consult the configuration setups, as well as conventions used by other user communities with which they may want to interoperate.  This will help them to assess whether these two communities will be able to interoperate, or under what conditions.

 

This Deployment Profile Template specification is intended to replace the previous Deployment Guide Template document [ebDPT], which should be seen as a previous version of such a deployment template for ebMS.

1.2 Terminology

The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in Error! Reference source not found..

Source Specification: The specification or standard that is being profiled.

Deployment Profile Template: Document that lists the options in the source specification that may be selected by a user community, that identifies content elements (e.g. message headers, XML values) the format and/or value of which may be further standardized by a community, and that also identifies typical operating conditions under which the source specification may be used, and selected by a user community.

User Community: A group of users, e.g. within a supply-chain industry, the members of which decide to make a similar usage of the source specification in order to be able to interoperate.

Deployment Profile (or Deplyment Guide): Document that is an instance of the Deployment Profile Template. It defines which options should / should not be used by this community, which format or value some content elements should comply with, and under which operating conditions the standard must be used by this community.

1.3 How to Use the Deployment Profile Template

There are three parts in the Deployment Profile Template that need to be instantiated in order to generate a Deployment Profile:

The section on the source specification modules (see section 2 below)

The section on the profiling requirement details (see section 3 below)

The section on operating conditions associated with the profile (see section 4 below)

Every feature from the source specification that is candidate for profiling is listed in a “profile requirement item” table of the form:

 

Specification Feature

<Description of the source specification item to be profiled. This is pre-filled in the Deployment Profile Template.>

Specification Reference

<Identifies the item in the source specification. This is pre-filled in the Deployment Profile Template >

Profiling

<how the item is profiled: option narrowing/selection, content formatting,
narrowing structure of XML complex element, content integrity constraint,.... This is left for a Deployment Profile to fill in. >

Alignment

<dependency / alignment with other data, e.g. binding, either with other
item in this same specification, items from other ebXML specifications, or items specified in an external source, e.g. a domain-specific or industry-specific standard. This is left for a Deployment Profile to fill in. >

Test References

<references to related test requirements or test cases, that would verify
this profiling. This is left for a Deployment Profile to fill in. >

Notes

<Profile-specific comments.This is left for a Deployment Profile to fill in.>

 

When no recommendation is made for a profile requirement item of the template, one of the following values MUST be used in the “profiling” and “alignment” fields of the table:

Not Applicable: for items that are not relevant to the community.

No Recommendation: will indicate that there is no recommendation or requirement for this feature item.

Pending: for items that are still under study for a recommendation, and for which some recommendation is likely to be specified in future versions of the Deployment Profile (yet, the user community did not want to wait for these to be specified before publishing a current version of the Profile or Guide).

 

For items that specify text values, it should also be noted whether or not the values are case-sensitive.

 

Two classes of users would be expected to collaborate in the instantiation of this Template to produce a Deployment Guide (or Profile):

Business Process Designers would detail the business-process specific requirements of the Message Service.

Technical Architects in user communities or vertical industries would make the technical decisions necessary to implement the business processes most effectively.

Consumers of a Deployment Guide include:

        Business process implementers (IT departments), to deploy a Message Service solution according to the requirements of specific trading communities.

        Software solution vendors, to identify all areas in which business process specification bodies require software flexibility, and what specific configurations are necessary to support such standards.

 

Examples shown in the “Profiling” field of Profile Requirement items are non-normative, having been provided by a User community (here EAN•UCC) based upon that organization’s experience using this template, and should be replaced with text appropriate to the Deployment Guide developer’s organization.

 

When populating the Template, it is possible that a deployment requirement can have more than one answer.  For example, when a requirement maps to a CPA element, users may want to specify several authorized values, as this community may want to allow more than one choice, to be further described by specific CPAs.  In that case, and if CPAs are already defined, it is recommended to annotate each value with the CPA identification it will relate to.  By doing so, the resulting Deployment Guide will give an overview of all the possible uses for a particular MSH feature (e.g. Security).  This will help to quickly assess the deployment requirements for this particular feature.  An alternative would be to provide pointers to existing CPAs, which the Template also allows.  However, these CPAs may change in time (updates, additions).  It is the role of the Deployment Guide to precisely show what capabilities are expected from a deployed implementation within a community. CPA designers will use it as a reference, so that new CPAs remain within these capabilities.

2           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 yes, some profiling details should be given for this module in section 3 or 4.

 

2.1 Core Modules

Module Name and Reference

Core Extension Elements (section 3)

Profiling Status

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

Profiled: <yes / no>

Notes

 

 

Module Name and Reference

Security Module (section 4.1)

Profiling Status

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

Profiled: <yes / no>

Notes

 

 

Module Name and Reference

SyncReply Module (section 4.3)

Profiling Status

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

Profiled: <yes / no>

Notes

 

 

2.2 Additional Modules

Module Name and Reference

Reliable Messaging Module (section 6)

Profiling Status

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

Profiled: <yes / no>

Notes

 

 

Module Name and Reference

Message Status Service (section 7)

Profiling Status

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

Profiled: <yes / no>

Notes

 

 

Module Name and Reference

Ping Service (section 8)

Profiling Status

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

Profiled: <yes / no>

Notes

 

 

Module Name and Reference

Message Order (section 9)

Profiling Status

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

Profiled: <yes / no>

Notes

 

 

Module Name and Reference

Multi-Hop (section 10)

Profiling Status

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

Profiled: <yes / no>

Notes

 

 

2.3 Communication Protocol Bindings

2.3.1 Profile Requirement Item: Transport Protocol

Specification Feature

Header elements:

Specification Reference

ebMS 2, Appendix B

Profiling (a)

Is HTTP a required or allowed transfer protocol?  (See section B.2 for specifics of this protocol.)

Profiling (b)

Is HTTPS a required or allowed transfer protocol?  (See section B.2 for specifics of this protocol.)

Profiling (c)

Is (E)SMTP a required or allowed transfer protocol?  (See section B.3 for specifics of this protocol.)

Profiling (d)

If SMTP, What is needed in addition to the ebMS minimum requirements for SMTP?

Profiling (e)

Are any transfer protocols other than HTTP and SMTP allowed or required?  If so, describe the protocol binding to be used.

Alignment

 

Test References

 

Notes

 

3           Profile Requirements Details

3.1 Module: Core Extension Elements

3.1.1 Profile Requirement Item: PartyId

Specification Feature

In message Header:

/SOAP:Header/eb:MessageHeader/eb:From/eb:PartyId

/SOAP:Header/eb:MessageHeader/eb:To/eb:PartyId

Is a specific standard used for party identification?  Provide details.

Specification Reference

ebMS 2, section 3.1.1.1 PartyId Element

 

Profiling (a)

Is a specific standard used for party identification?  Provide details. Example - EAN•UCC Global Location Number. Ref.: ISO6523 - ICD0088.

 

Profiling (b)

Should multiple PartyId elements be present in From and To elements?  [See section 3.1.1.1 of Business-Level Requirements.  ]

 

Profiling (c)

Is the type attribute needed for each PartyId, and if so, what must it contain?

Example – within the EAN•UCC system, the PartyId element and type are represented using Global Location Number.

<eb:PartyId eb:type="http:/www.iso.int/schemas/eanucc/gln">1234567890128</eb:PartyId>

Alignment

appears as PartyId element in CPA.

(c) appears as PartyId/@type in CPA

Test References

 

Notes

 

 

3.1.2 Profile Requirement Item: Role

Specification Feature

Header elements:

/SOAP:Header/eb:MessageHeader/eb:From/eb:Role

/SOAP:Header/eb:MessageHeader/eb:To/eb: Role

Specification Reference

ebMS 2, section 3.1.1.2  “Role Element”

Profiling

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.ean-ucc.org/roles/seller</eb:Role>

Alignment

[Per-process; may reference Role values in BPSS [ebBP] definitions.  Appears as Role/@name in CPA.]

Test References

 

Notes

 

 

3.1.3 Profile Requirement Item: CPAId

Specification Feature

Header elements:

/SOAP:Header/eb:MessageHeader/eb:CPAId

Specification Reference

ebMS 2, section 3.1.2

Profiling

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

Alignment

Appears as CollaborationProtocolAgreement/@cpaid in CPA.

Test References

 

Notes

 

 

3.1.4 Profile Requirement Item: ConversationId

Specification Feature

Header elements:

/SOAP:Header/eb:MessageHeader/eb:ConversationId

Specification Reference

ebMS 2, section 3.1.3

Profiling (a)

What is the user definition of a Conversation? What is the business criterion used to correlate messages considered parts of the same conversation?

Profiling (b)

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?

           

Alignment

If BPSS is used, ConversationId typically maps to a  business transaction. Is that the case? Does it map instead to a business collaboration?

Test References

 

Notes

 

 

3.1.5 Profile Requirement Item: MessageId

Specification Feature

Header elements:

/SOAP:Header/eb:MessageHeader/eb:MessageData/eb:MessageId

Specification Reference

ebMS 2, section 3.1.6.1

Profiling (a)

Although there is no requirement for an MSH to give control about MessageID to an application, some implementations may allow this. In this case,  is there any requirement on the source of this ID? Any length and format restrictions if the ID is generated?

Alignment

 

Test References

 

Notes

 

 

3.1.6 Profile Requirement Item: Service

Specification Feature

Header elements:

/SOAP:Header/eb:MessageHeader/eb:Service

/SOAP:Header/eb:MessageHeader/eb:Service/@type

Specification Reference

ebMS 2, section 3.1.4

Profiling (a)

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?

Profiling (b)

Is there a defined "type" for Service elements?  If so, what value must the type attribute contain?

Alignment

Appears as Service element in CPA

Appears as Service/@type in CPA

Test References

 

Notes

 

 

3.1.7 Profile Requirement Item: Action

Specification Feature

Header elements:

/SOAP:Header/eb:MessageHeader/eb:Action

Specification Reference

ebMS 2, section 3.1.5

Profiling

Are Actions defined for each party to each business process?  List them, or provide a reference to the source of these values.  [Per-process; may reference BusinessAction values in BPSS definitions.

Example – within the EAN•UCC system, approved values are specified by the EAN•UCC Message Service Implementation Guide.

<eb:Action>Confirmation</eb:Action>

Alignment

Appears as ThisPartyActionBinding/@action in CPA.]

Test References

 

Notes

 

 

3.1.8 Profile Requirement Item: Timestamp

Specification Feature

Header elements:

/SOAP:Header/eb:MessageHeader/eb:MessageData/eb:Timestamp

/SOAP:Header/eb:MessageHeader/ eb:Acknowledgment/eb:Timestamp

Specification Reference

ebMS 2, section 3.1.6.2, 6.3.2.2, 6.4.5, 7.3.2

Profiling

Must Timestamp include the 'Z' (UTC) identifier?

Alignment

 

Test References

 

Notes

 

 

3.1.9 Profile Requirement Item: Description

Specification Feature

Header elements:

/SOAP:Header/eb:MessageHeader/eb:Description

Specification Reference

ebMS 2, section 3.1.8

Profiling

Are one or more Message Header Description elements required?  In what language(s)?  Is there a convention for its contents?

Alignment

 

Test References

 

Notes

 

 

3.1.10 Profile Requirement Item: Manifest

Specification Feature

Header elements:

/SOAP:Body/eb:Manifest

 

Specification Reference

ebMS 2, section 3.2.2

Profiling (a)

How many Manifest elements must be present, and what must they reference?

Does the order of Manifest elements have to match the order of the referenced MIME attachments? Any restriction on the range of value for xlink:reference (e.g. nothing other than

content id references)?

Profiling (b)

Must a URI that cannot be resolved be reported as an error?

Alignment

 

Test References

 

Notes

 

 

3.1.11 Profile Requirement Item: Reference

Specification Feature

Header elements:

/SOAP:Body/eb:Manifest/eb:Reference

 

Specification Reference

ebMS 2, section 3.2.1

Profiling (a)

Is the xlink:role attribute required?  What is its value?

Profiling (b)

Are any other namespace-qualified attributes required?

Alignment

 

Test References

 

Notes

 

 

3.1.12 Profile Requirement Item: Reference/Schema

Specification Feature

Header elements:

/SOAP:Body/eb:Manifest/eb:Reference/eb:Schema

 

Specification Reference

ebMS 2, section 3.2.1.1

Profiling

Are there any Schema elements required?  If so, what are their location and version attributes?

Alignment

 

Test References

 

Notes

 

 

3.1.13 Profile Requirement Item: Reference/Description

Specification Feature

Header elements:

/SOAP:Body/eb:Manifest/eb:Reference/eb:Description

 

Specification Reference

ebMS 2, section 3.2.1.2

Profiling

Are any Description elements required?  If so, what are their contents?

Alignment

 

Test References

 

Notes

 

 

3.2 Module: Security

3.2.1 Profile Requirement Item: Signature generation

Specification Feature

Header elements:

/SOAP:Header/Signature

Specification Reference

ebMS 2, section 4.1.4.1

Profiling (a)

Must messages be digitally signed?  [Yes, for Security Services Profiles 1, 6-21. 

Profiling (b)

Are additional Signature elements required, by whom, and what should they reference?

Profiling (c)

What canonicalization method(s) must be applied to the data to be signed?  [Recommended method is "http://www.w3.org/TR/2001/REC-xml-c14n-20010315".]

Profiling (d)

What canonicalization method(s) must be applied to each payload object, if different from above?

Profiling (e)

What signature method(s) must be applied?

Profiling (f)

What Certificate Authorities (issuers) are allowed or required for signing certificates?

Profiling (g)

Are direct-trusted (or self-signed) signing certificates allowed?

Profiling (h)

What certificate verification policies and procedures must be followed?

Alignment

(a) Appears as BusinessTransactionCharacteristics/@isAuthenticated=persistent and BusinessTransactionCharacteristics/@isTamperProof=persistent in CPA

Test References

 

Notes

 

 

3.2.2 Profile Requirement Item: Persistent Signed Receipt

Specification Feature

Header elements:

/SOAP:Header/eb:Signature

Specification Reference

ebMS 2, section 4.1.4.2

Profiling (a)

Is a digitally signed Acknowledgment message required?  [Yes, for Security Services Profiles 7, 8, 10, 12, 14, 15, 17, 19-21.  See the items beginning with Section 4.1.4.1 for specific Signature requirements.  ]

Profiling (b)

If so, what is the Acknowledgment or Receipt schema?

 

Alignment

Appears as BusinessTransactionCharacteristics/@isNonRepudiationReceiptRequired=persistent in CPA.

Test References

 

Notes

 

 

3.2.3 Profile Requirement Item: Non Persistent Authentication

Specification Feature

Header elements:

/SOAP:Header/eb:Signature

Specification Reference

ebMS 2, section 4.1.4.3

Profiling

Are communication channel authentication methods required?  [Yes, for Security Services Profiles 2-5.]

Which methods are allowed or required?

 

Alignment

[Appears as BusinessTransactionCharacteristics/@isAuthenticated=transient in CPA.]

Test References

 

Notes

 

 

3.2.4 Profile Requirement Item: Non Persistent Integrity

Specification Feature

Header elements:

/SOAP:Header/eb:Signature

Specification Reference

ebMS 2, section 4.1.4.4.

Profiling

Are communication channel integrity methods required? [Yes, for Security Services Profile 4.]

Which methods are allowed or required?

 

Alignment

[Appears as BusinessTransactionCharacteristics/@isTamperproof=transient in CPA.]

Test References

 

Notes

 

 

3.2.5 Profile Requirement Item: Persistent Confidentiality

Specification Feature

Header elements:

/SOAP:Header/eb:Signature

Specification Reference

ebMS 2, section 4.1.4.5

Profiling (a)

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

Profiling (b)

Is payload confidentiality (encryption) required?  [Yes, for Security Services Profiles 13, 14, 16, 17, 21, 22.]

Which methods are allowed or required?

 

Alignment

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

Test References

 

Notes

 

 

3.2.6 Profile Requirement Item: Non Persistent Confidentiality

Specification Feature

Header elements:

/SOAP:Header/eb:Signature

Specification Reference

ebMS 2, section 4.1.4.6

Profiling

Are communication channel confidentiality methods required?  [Yes, for Security Services Profiles 3, 6, 8, 11, 12.]

Which methods are allowed or required?

 

Alignment

[Appears as BusinessTransactionCharacteristics/@isConfidential=transient in CPA.]

Test References

 

Notes

 

 

3.2.7 Profile Requirement Item: Persistent Authorization

Specification Feature

Header elements:

/SOAP:Header/eb:Signature

Specification Reference

ebMS 2, section 4.1.4.7

Profiling

Are persistent authorization methods required?  [Yes, for Security Services Profiles 18-21.]

Which methods are allowed or required?

 

Alignment

[Appears as BusinessTransactionCharacteristics/@isAuthorizationRequired=persistent in CPA.]

Test References

 

Notes

 

 

3.2.8 Profile Requirement Item: Non Persistent Authorization

Specification Feature

Header elements:

/SOAP:Header/eb:Signature

Specification Reference

ebMS 2, section 4.1.4.8

Profiling

Are communication channel authorization methods required?  [Yes, for Security Services Profile 2.]

Which methods are allowed or required?

 

Alignment

[Appears as BusinessTransactionCharacteristics/@isAuthorizationRequired=transient in CPA.]

Test References

 

Notes

 

 

3.2.9 Profile Requirement Item: Trusted Timestamp

Specification Feature

Header elements:

/SOAP:Header/eb:Signature

Specification Reference

ebMS 2, section 4.1.4.9

Profiling

Is a trusted timestamp required?  [Yes, for Security Services Profiles 9-12, 15-17, 20, 21.]  If so, provide details regarding its usage.

Alignment

 

Test References

 

Notes

 

 

3.3 Module : Error Handling

3.3.1 Profile Requirement Item:

Specification Feature

Header elements:

/SOAP:Header/eb:ErrorList/eb:Error

/SOAP:Header/eb:ErrorList/ eb:Error/@codeContext

/SOAP:Header/eb:ErrorList/ eb:Error/@errorCode

Specification Reference

ebMS 2, section 4.2.3.2.

Profiling (a)

Is an alternative codeContext used?  If so, specify

Profiling (b)

If an alternative codeContext is used, what is its errorCode list?

Profiling (c)

When errors should be reported to the sending application, how should this notification be performed (e.g. using a logging mechanism or a proactive callback)?

Alignment

 

Test References

 

Notes

 

 

3.4 Module : SyncReply

3.4.1 Profile Requirement Item: SyncReply

Specification Feature

Header elements:

/SOAP:Header/eb:SyncReply/

Specification Reference

ebMS 2, section 4.3

Profiling (a)

Is SyncReply mode allowed, disallowed, or required, and under what circumstances?  [May be process-specific.]

Profiling (b)

If SyncReply mode is used, are MSH signals, business messages or both expected synchronously?

Alignment

[Affects setting of 6.4.7 syncReplyMode element.  Appears as MessagingCharacteristics/@syncReplyMode in CPA.]

Test References

 

Notes

 

 

3.5 Module : Reliable Messaging

3.5.1 Profile Requirement Item: SOAP Actor attribute

Specification Feature

Header elements:

/SOAP:Header/eb:AckRequested/

Specification Reference

ebMS 2, section 6.3.1.1

Profiling (a)

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

Profiling (b)

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

Test References

 

Notes

 

 

3.5.2 Profile Requirement Item: Signed attribute

Specification Feature

Header elements:

/SOAP:Header/eb:AckRequested/

Specification Reference

ebMS 2, section 6.3.1.2

Profiling

Must MSH Acknowledgments be (requested to be) signed ?

Alignment

[Appears as MessagingCharacteristics/@ackSignatureRequested in CPA.]

Test References

 

Notes

 

 

3.5.3 Profile Requirement Item: DuplicateElimination

Specification Feature

Header elements:

/SOAP:Header/eb:AckRequested/

Specification Reference

ebMS 2, section 6.4.1

Profiling (a)

Is elimination of duplicate messages required?  [Yes, for RM Combinations 1-4.  .]

Profiling (b)

What is the expected scope in time of duplicate elimination?  In other words, how long should messages or message Ids be kept in persistent storage for this purpose?

Alignment

Appears as MessagingCharacteristics/@duplicateElimination in CPA

Test References

 

Notes

 

 

3.5.4 Profile Requirement Item: Retries and RetryInterval

Specification Feature

Header elements:

/SOAP:Header/eb:AckRequested/

Specification Reference

ebMS 2, section 6.4.3, 6.4.4

Profiling (a)

If reliable messaging is used, how many times must an MSH attempt to redeliver an unacknowledged message? 

Profiling (b)

What is the minimum time a Sending MSH should wait between retries of an unacknowledged message?

Alignment

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

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

Test References

 

Notes

 

 

3.5.5 Profile Requirement Item: PersistDuration

Specification Feature

Header elements:

 

Specification Reference

ebMS 2, section 6.4.6

Profiling

How long must data from a reliably sent message be kept in persistent storage by a receiving MSH, for the purpose of retransmission? 

Alignment

[Appears as ReliableMessaging/PersistDuration in CPA.]

Test References

 

Notes

 

 

3.5.6 Profile Requirement Item: Reliability Protocol

Specification Feature

Header elements:

 

Specification Reference

ebMS 2, section 6.5.3, 6.5.7

Profiling (a)

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?

Profiling (b)

If a DeliveryFailure error message cannot be delivered successfully, how must the error message's destination party be informed of the problem?

Alignment

 

Test References

 

Notes

 

 

3.6 Module : Message Status

3.6.1 Profile Requirement Item: Status Request message

Specification Feature

Header elements:

Eb:MessageHeader/eb:StatusRequest

Specification Reference

ebMS 2, section 7.1.1

Profiling (a)

If used, must Message Status Request Messages be digitally signed?

Profiling (b)

Must unauthorized Message Status Request messages be ignored, rather than responded to, due to security concerns?

Alignment

 

Test References

 

Notes

 

 

3.6.2 Profile Requirement Item: Status Response message

Specification Feature

Header elements:

Eb:MessageHeader/eb:StatusResponse

Specification Reference

ebMS 2, section 7.1.2

Profiling

If used, must Message Status Response Messages be digitally signed?

Alignment

 

Test References

 

Notes

 

 

3.7 Module : Ping Service

3.7.1 Profile Requirement Item: Ping-Pong Security

Specification Feature

Header elements:

Eb:MessageHeader/eb:Service

Eb:MessageHeader/eb:Action

Specification Reference

ebMS 2, section 8.1, 8.2

Profiling (a)

If used, must Ping Messages be digitally signed?

Profiling (b)

If used, must Pong Messages be digitally signed?

Profiling (c)

Under what circumstances must a Pong Message not be sent?

Profiling (d)

If not supported or unauthorized, must the MSH receiving a Ping respond with an error message, or ignore it due to security concerns?

Alignment

 

Test References

 

Notes

 

 

3.8 Module : Multi-Hop

3.8.1 Profile Requirement Item: Use of intermediaries

Specification Feature

Header elements:

Specification Reference

ebMS 2, section 10

Profiling (a)

Are any store-and-forward intermediary MSH nodes present in the message path?

Profiling (b)

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

Alignment

 

Test References

 

Notes

 

 

3.8.2 Profile Requirement Item: Acknowledgements

Specification Feature

Header elements:

Eb:MessageHeader/

Specification Reference

ebMS 2, section 10.1.1, 10.1.3

Profiling (a)

Must each intermediary request acknowledgment from the next MSH?

Profiling (b)

Must each intermediary return an Intermediate Acknowledgment Message synchronously?

Profiling (c)

If both intermediary (multi-hop) and endpoint acknowledgments are requested of the To Party, must they both be sent in the same message?

Alignment

 

Test References

 

Notes

 

 

3.9 SOAP Extensions

3.9.1 Profile Requirement Item: #wildCard, Id

Specification Feature

Header elements:

 

Specification Reference

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

 

 

3.10 MIME Header Container

3.10.1 Profile Requirement Item: charset

Specification Feature

MIME Header elements:

Content-Type

Specification Reference

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

 

Notes

 

 

 

 

3.11 HTTP Binding

3.11.1 Profile Requirement Item: HTTP Headers

Specification Feature

Header elements, MIME parts

Specification Reference

ebMS 2, Appendix B.2.2.

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

 

 

3.11.2 Profile Requirement Item: HTTP Response Codes

Specification Feature

Header elements, MIME parts

Specification Reference

ebMS 2, Appendix B.2.3.

Profiling

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

Alignment

 

Test References

 

Notes

 

 

3.11.3 Profile Requirement Item: HTTP Access Control

Specification Feature

Header elements, MIME parts

Specification Reference

ebMS 2, Appendix B.2.6.

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

 

 

3.11.4 Profile Requirement Item: HTTP Confidentiality and Security

Specification Feature

Header elements, MIME parts

Specification Reference

ebMS 2, Appendix B.2.7.

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?

Profiling (f)

What client Certificate Authorities are acceptable?

Profiling (g)

What certificate verification policies and procedures must be followed?

Alignment

 

Test References

 

Notes

 

 

3.12 SMTP Binding

3.12.1 Profile Requirement Item: MIME Headers

Specification Feature

Header elements, MIME parts

Specification Reference

ebMS 2, Appendix B.3.2.

Profiling (a)

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

Profiling (b)

If other than "ebXML" what must the SOAPAction SMTP header field contain?

Profiling (c)

What additional MIME headers must be included among the SMTP headers?

Alignment

 

Test References

 

Notes

 

 

3.12.2 Profile Requirement Item: SMTP Confidentiality and Security

Specification Feature

Header elements, MIME parts

Specification Reference

ebMS 2, Appendix B.3.4, B.3.5

Profiling (a)

What SMTP access control mechanisms are required?  [Refer to item 4.1.4.8 in Security section.]

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

Alignment

 

Test References

 

Notes

 

4           Operational Profile

This 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.1 Deployment and Processing requirements for CPAs

CPA Access

Profile requirements

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

 

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

 

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

 

Others

 

 

4.2 Security Profile

Security 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?

 

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?

 

Others

 

 

4.3 Reliability Profile

Reliability Profile

Profile requirements

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

 

Others

 

 

4.4 Error Handling Profile

Error 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?

 

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?

 

(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

 

 

4.5 Message Payload and Flow Profile

Message Quantitative Aspects

Profile requirements

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?

 

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?  

 

Others

 

 

4.6 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?

 

 

 

 

4.7 Additional Deployment or Operational Requirements

Operational or Deployment Conditions

Profile requirements

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

Recommended or required practices.

 

 

5           References

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

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

5.2 Non-Normative

[ebCPPA]               OASIS, ebXML Collaboration-Protocol Profile and Agreement Specification Version 2.0, http://www.oasis-open.org/committees/download.php/204/ebcpp-2.0.pdf, September 23, 2002.

[ebDPT]                  OASIS, Metadata for Deployment Profile Templates, http://www.oasis-open.org/committees/download.php/19253/ebxml-iic-Deployment_Profile_Template-CD.doc.

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

 

Appendix A. Acknowledgments

In 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. <mike@drummondgroup.com>

Jeffery Eck, Global Exchange Services <Jeffery.Eck@gxs.ge.com>

Aaron Gomez, Drummond Group Inc. <aaron@drummondgroup.com>

Michael Kass, NIST <michael.kass@nist.gov>

Matthew MacKenzie, Individual <matt@mac-kenzie.net>

Tim Sakach, Drake Certivo <http://www.oasis-open.org/apps/org/workgroup/ebxml-iic/members/wg_person.php?workgroup_person_id=5041tsakach@certivo.net>

Jeff Turpin, Cyclone Commerce <jturpin@cyclonecommerce.com>

Eric van Lydegraf  Kinzan <ericv@kinzan.com>

Steven Yung, Sun Microsystems <steven.yung@sun.com>

Appendix B. Revision History

Rev

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

8 June, 2005

J. Durand

Recast the previous document in new Deployment Template format, plus some editorial corrections.