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, i n 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. C lients 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 s ection 5.1, also be a conformant implementation of the EDIINT Applicability Statement 2 (AS2, [RFC4130]). Pim From: Pim van der Eijk [mailto:
pvde@sonnenglanz.net] Sent: 22 February 2011 10:48 To:
ebxml-msg@lists.oasis-open.org 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