OASIS ebXML Messaging Services TC

  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    

Some feedback from our sw development dept 'Doc update looks good, more accurate, I see we're going to have to add a ReceptionAwareness flag to the pmode'. On the doc structure - section 2.2.3 - numbering for General PMode parameters starts at 0 and is not 'automated' ie. the 0 is manually typed in. 0. General PMode parameters: On 22 Feb 2011, at 11:47 AM, Pim van der Eijk wrote: > > 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 > > -- Regards Theo

  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    

Hello,   Here are the URLs for the document we just approved as CSD 03.   ODT: http://www.oasis-open.org/apps/org/workgroup/ebxml-msg-as4/document.php?document_id=41252   ODT with diffs to CS: http://www.oasis-open.org/apps/org/workgroup/ebxml-msg-as4/document.php?document_id=41253   PDF: http://www.oasis-open.org/apps/org/workgroup/ebxml-msg-as4/document.php?document_id=41254   HTML: http://www.oasis-open.org/apps/org/workgroup/ebxml-msg-as4/document.php?document_id=41255   It also incorporates results of the discussion mentioned below that we just discussed and decided on during our meeting.   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    

I spent some time with our chief sw developer reviewing the latest draft of CSD03 for AS4 with the view of preparing our statement of use, and any changes that we would need to make to conform to the spec. I noted that, amongst others, there appear to be areas that raise questions and areas that would benefit the reader if rephrased. Some of the questions raised include the following Section 2.2.3.6 Pmode[1].Security.SendReceipt.ReplyPattern: support required (for "response")) should this not read Pmode[1].Security.SendReceipt.ReplyPattern: support required (for "callback") ? Section 3.4 Lines 567 to 570 (para 2 of 3.4) The phrase '... both as a business receipt...' appears incorrect as the MSH does not guarantee receipt of a message by the consumer application - see bullet (b) in the following paragraph. Should this not simply be '... both as a receipt...' ? I understand that a vote was passed to have csd03 for as4 submitted for public review of 15 days and am wondering if TC members are excluded from participating in the public review. Please advise if that is the case, and if so what the process would be for addressing the issues that I have. On 23 Feb 2011, at 10:40 PM, Pim van der Eijk wrote: > Hello, > > Here are the URLs for the document we just approved as CSD 03. > > ODT: > http://www.oasis-open.org/apps/org/workgroup/ebxml-msg-as4/document.php?document_id=41252 > > ODT with diffs to CS: > http://www.oasis-open.org/apps/org/workgroup/ebxml-msg-as4/document.php?document_id=41253 > > PDF: > http://www.oasis-open.org/apps/org/workgroup/ebxml-msg-as4/document.php?document_id=41254 > > HTML: > http://www.oasis-open.org/apps/org/workgroup/ebxml-msg-as4/document.php?document_id=41255 > > It also incorporates results of the discussion mentioned below that we just discussed and decided on during our meeting. > > Pim > -- Regards Theo

Inline <JD>
Original Message----- From: Theo Kramer [ mailto:theo@flame.co.za ] Sent: Tuesday, March 01, 2011 12:16 PM To: ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] CSD03 for AS4 I spent some time with our chief sw developer reviewing the latest draft of CSD03 for AS4 with the view of preparing our statement of use, and any changes that we would need to make to conform to the spec. I noted that, amongst others, there appear to be areas that raise questions and areas that would benefit the reader if rephrased. Some of the questions raised include the following Section 2.2.3.6 Pmode[1].Security.SendReceipt.ReplyPattern: support required (for "response")) should this not read Pmode[1].Security.SendReceipt.ReplyPattern: support required (for "callback") ? <JD> Only when the "Light Client" is acting as a Receiver for the (pulled) one-way. For a one-way / push, this is still "response". But you put the finger on the fact that the PMode displayed here is only for the One-way / Push, initiated by the Light Client. Either we just say that explicitly, or we should also introduce alternative PMode values when the PMode.MEPbinding is "pull". In which case we should say: Pmode[1].Security.SendReceipt.ReplyPattern: support required (for "response" if PMode.MEPbinding is "push", and for "callback" if PMode.MEPbinding is "pull".)) Section 3.4 Lines 567 to 570 (para 2 of 3.4) The phrase '... both as a business receipt...' appears incorrect as the MSH does not guarantee receipt of a message by the consumer application - see bullet (b) in the following paragraph. Should this not simply be '... both as a receipt...' ? <JD> but isn't it still a business receipt (even if it does not reach the final application destination)...? In other words, it may be a "failed" business receipt if not delivered. I understand that a vote was passed to have csd03 for as4 submitted for public review of 15 days and am wondering if TC members are excluded from participating in the public review. <JD> TC members can also produce comments I understand. Maybe we should address these before proceeding further... Please advise if that is the case, and if so what the process would be for addressing the issues that I have. On 23 Feb 2011, at 10:40 PM, Pim van der Eijk wrote: > Hello, > > Here are the URLs for the document we just approved as CSD 03. > > ODT: > http://www.oasis-open.org/apps/org/workgroup/ebxml-msg-as4/document.php?document_id=41252 > > ODT with diffs to CS: > http://www.oasis-open.org/apps/org/workgroup/ebxml-msg-as4/document.php?document_id=41253 > > PDF: > http://www.oasis-open.org/apps/org/workgroup/ebxml-msg-as4/document.php?document_id=41254 > > HTML: > http://www.oasis-open.org/apps/org/workgroup/ebxml-msg-as4/document.php?document_id=41255 > > It also incorporates results of the discussion mentioned below that we just discussed and decided on during our meeting. > > Pim > -- Regards Theo --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

On 02 Mar 2011, at 4:12 AM, Jacques Durand wrote: > Inline <JD> <snip> > Section 3.4 > Lines 567 to 570 (para 2 of 3.4) > The phrase '... both as a business receipt...' appears incorrect as the MSH does not guarantee receipt of a message by the consumer application - see bullet (b) in the following paragraph. > > Should this not simply be '... both as a receipt...' ? > > <JD> but isn't it still a business receipt (even if it does not reach the final application destination)...? In other words, it may be a "failed" business receipt if not delivered. My understanding of a 'business receipt' is exactly that, ie. the business has received the message and the receipt is the notification thereof. <snip> -- Regards Theo

The use of the phrase 'business receipt' in AS4 was to distinguish the nature of the AS4/ebMS3 receipt as being sufficient for NRR (non-repuation of receipt). In this sense it is very similar to the RFC3798 Message Disposition Notification response that is used by AS2 as a business receipt for non-repudiation. This receipt in AS4/ebMS3 contains the same information as the MDN, and thus distinguishes itself from the ebMS2 'acknowledgment' or web services reliable messaging acknowledgment. On 3/2/2011 7:26 AM, Theo Kramer wrote: > > My understanding of a 'business receipt' is exactly that, ie. the business has received the message and the receipt is the notification thereof. > > <snip>

On 02 Mar 2011, at 11:00 PM, Timothy Bennett wrote: > The use of the phrase 'business receipt' in AS4 was to distinguish the nature of the AS4/ebMS3 receipt as being sufficient for NRR (non-repuation of receipt). In this sense it is very similar to the RFC3798 Message Disposition Notification response that is used by AS2 as a business receipt for non-repudiation. This receipt in AS4/ebMS3 contains the same information as the MDN, and thus distinguishes itself from the ebMS2 'acknowledgment' or web services reliable messaging acknowledgment. > Thanks - trust you would be ok if I 'lift' this and add it to the draft... -- Regards Theo

Assuming Jacques is OK with it, then yes it is OK with me. On 3/3/2011 4:41 AM, Theo Kramer wrote: > On 02 Mar 2011, at 11:00 PM, Timothy Bennett wrote: > >> The use of the phrase 'business receipt' in AS4 was to distinguish the nature of the AS4/ebMS3 receipt as being sufficient for NRR (non-repuation of receipt). In this sense it is very similar to the RFC3798 Message Disposition Notification response that is used by AS2 as a business receipt for non-repudiation. This receipt in AS4/ebMS3 contains the same information as the MDN, and thus distinguishes itself from the ebMS2 'acknowledgment' or web services reliable messaging acknowledgment. >> > Thanks - trust you would be ok if I 'lift' this and add it to the draft... >

That is a good explanation to add (so Theo it is for you to add to your upcoming comments). To be more specific on why "business receipt" and not just "receipt": - business receipts (when received) are supposed to go up the stack from message handler to application. - plain "receipts" (as in reliable messaging or acks) are not supposed to go up the stack: just for the messg handler to process and react to. -jacques
Original Message----- From: Timothy Bennett [ mailto:timothy@drummondgroup.com ] Sent: Thursday, March 03, 2011 8:57 AM To: ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] CSD03 for AS4 Assuming Jacques is OK with it, then yes it is OK with me. On 3/3/2011 4:41 AM, Theo Kramer wrote: > On 02 Mar 2011, at 11:00 PM, Timothy Bennett wrote: > >> The use of the phrase 'business receipt' in AS4 was to distinguish the nature of the AS4/ebMS3 receipt as being sufficient for NRR (non-repuation of receipt). In this sense it is very similar to the RFC3798 Message Disposition Notification response that is used by AS2 as a business receipt for non-repudiation. This receipt in AS4/ebMS3 contains the same information as the MDN, and thus distinguishes itself from the ebMS2 'acknowledgment' or web services reliable messaging acknowledgment. >> > Thanks - trust you would be ok if I 'lift' this and add it to the draft... > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Replying to this as it was copied in the AS4 draft spec: I agree with you on the sequence acknowledgments, but the ebMS 2.0 receipt actually does seem to support NRR because an eb2:Acknowledgment includes: 1) The unique identifier of the received message 2) A digest value(s) of the received message (parts) 3) A timestamp when the receipt occurred 4) A signature covering 1, 2 and 4 above Here is an example (from a test message I generated years ago) that illustrates (1)-(4): <eb:Acknowledgment eb:version="2.0"soap:actor="urn:oasis:names:tc:ebxml-msg:act or:toPartyMSH" soap:mustUnderstand="1"> <eb:Timestamp>2006-09-27T07:16:59.648Z</eb:Timestamp> <eb:RefToMessageId>M1159341395913.998@sonyvaio_cn26151260552 81300265</eb:RefToMessageId> <eb:From> <eb:PartyId eb:type="string">Partner D</eb:PartyId><eb:Role>OM</eb:Role> </eb:From> <ds:Reference URI="" xmlns:ds=" http://www.w3.org/2000/09/xmldsig#" ;> <ds:Transforms><-- omitted --></ds:Transforms> <ds:DigestMethod Algorithm=" http://www.w3.org/2000/09/xmldsig#sha1"/ > <ds:DigestValue>N1GimuMQPHhtBcD/oTaL5k0E0Ms=</ds:DigestValue > </ds:Reference> <ds:Reference URI=" cid:A1159341398217.1002@sonyvaio_cn" ; xmlns:ds=" http://www.w3.org/2000/09/xmldsig#" ;> <ds:DigestMethod Algorithm=" http://www.w3.org/2000/09/xmldsig#sha1"/ > <ds:DigestValue>FkwnI8mmXh71J5qcwO404ZnlXpg=</ds:DigestValue > </ds:Reference> </eb:Acknowledgment> Pim
Original Message----- From: Timothy Bennett [ mailto:timothy@drummondgroup.com ] Sent: 02 March 2011 22:00 To: ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] CSD03 for AS4 The use of the phrase 'business receipt' in AS4 was to distinguish the nature of the AS4/ebMS3 receipt as being sufficient for NRR (non-repuation of receipt). In this sense it is very similar to the RFC3798 Message Disposition Notification response that is used by AS2 as a business receipt for non-repudiation. This receipt in AS4/ebMS3 contains the same information as the MDN, and thus distinguishes itself from the ebMS2 'acknowledgment' or web services reliable messaging acknowledgment. On 3/2/2011 7:26 AM, Theo Kramer wrote: > > My understanding of a 'business receipt' is exactly that, ie. the business has received the message and the receipt is the notification thereof. > > <snip> ------------------------------------------------------------ --------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_work groups.php