RE: [ebxml-msg] New drafts for AS4

Hello,

 

In preparation for our call, and to be ready in case someone 
wants to raise a motion to adopt the AS4 profile as a CSD, I am preparing a 
version of the spec with:

- the date set to today (23rd of February 2011 instead of 
22nd).   

- Some missing indentations/tabs in section 1.2 and 
1.3.

- A normative reference for the Username Token profile (not 
necessary, useful for the potential new 5.3 clause, 
see below):

[WSS11-UT] OASIS Standard, Web Services Security UsernameToken Profile 1.1. 
February 2006. http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf. 

- The word "first" added in the first numbered item in 
Appendix A.2 (to avoid confusion with the other WSS header mentioned in item (2) 
in that section).

- In appendic C, last row, yesterday's version renamed to "Rev 
06".

- In appendix C, last row, CSD 03 and today's 
date.

 

If we approve the spec as a CSD, I can upload this during 
our meeting. It is ODT with all changes marked.

 

Separately from this,  in yesterday's 
email I mentioned two potential additional conformance clauses.  These are 
not in the draft yet.

In case a majority during the meeting finds those clauses 
should be added to the profile, here is some proposed language for 
them:

 

5.3 AS4 
Basic Client Conformance Clause

 

In order to 
conform to the AS4 Basic Client Profile, an implementation MUST comply with all normative statements and 
requirements for the AS4 Light Client 
Conformance Clause stated in Section 5.2, with the exception that support 
for WS-Security is limited to support to support for the WS-Security 
UsernameToken profile [WSS11-UT], to be used for authorization of message 
pull signals.  Support for the 
WS-Security X.509 Certificate Token Profile 1.1 [WSS11-X509] is not 
REQUIRED. Clients and 
servers SHOULD use transport level 
security for message security for any message 
exchange.

 
5.4 
AS2/AS4 ebHandler Conformance Clause

 

In order to 
conform to the AS2/AS4 ebHandler Profile, an implementation MUST, in addition to 
supporting AS4 message exchanges that comply with all normative statements and 
requirements specified in section 5.1, also be a conformant implementation 
of  the EDIINT Applicability Statement 2 (AS2, [RFC4130]).

 

Pim

From: Pim van der Eijk 
[mailto:] 
Sent: 22 February 2011 
10:48
To: 
Subject: 
[ebxml-msg] New drafts for AS4

 

Hello,

 

Jacques and I worked 
on cleaning up the AS4 draft for the 2nd PR over the past few 
days. 

ODT 
source:
http://www.oasis-open.org/committees/document.php?document_id=41222

 

PDF export:
http://www.oasis-open.org/committees/document.php?document_id=41224

 

ODT source with diffs to the CS 
http://www.oasis-open.org/committees/document.php?document_id=41223

 

Those of you with 
AS4 implementations and/or WS-Security expertise, please have a look at the 
examples (one new) in section A.

 

This draft does not 
take into account some potential enhancements:

 

1) There has also 
been some discussion about splitting the Client Conformance Clause in two 
separate clauses,  

-  one 
requiring full WS-Security support (X.509 and UserName token) 

-  and the 
other only requiring the UserName token (relying on SSL/TLS to protect the 
message)

Advantage:  
even easier to implement and no PKI requirements  

Downside:   another conformance clause is 
confusing.

 

2) A conformance 
clause that requires support for AS2 and AS4,  like the "Gateway V2/V3" 
profiles require support for ebMS 2.0 and 3.0.

Advantage:  may 
increase acceptance of and confidence in AS4 in communities that are currently 
AS2 users.
Downside:   another conformance clause 
is confusing.

 

If the TC decides in 
favor of these changes, they can easily be added to the spec. 

 

Pim