[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - OASIS ebXML Messaging Services Version 3.0: Part 2, Advanced Features (v46) (ebMS3-part2-V49.odt) uploaded
Hello, On 2.9: WS-SecureConversation is not mentioned in the Core Spec, but it is becoming more widely used and is in the WS-I profiles. Other messaging frameworks are adopting it, so I think ebMS should provide support for it. Perhaps it should have its own (very short) chapter rather than be a subsection of the multi-hop draft. On 3.2.1: Yes, it should be wsu:Timestamp/wsu:Created The list for one way is an example. The point this is making that one way and (legs of) two way exchanges can be mixed. The statements in lines 1851-1853 are there to show that all cross references are at message unit level. There is no identity for the bundle. It does not specify anything new as it follows from the way bundling is set to work, but apparently this was not immediately clear to every reader. On 3.2.2: Message signing is handled at the WS-Security level. Receipt generation is handled at the ebMS level. This explains the different handling of message signing and receipt signing in bundles. The goal is that at WS-Security level there is no implementation difference between sending a message with just one user message unit (and its payloads) and a bundle with any added secondary units (and their payloads). This way we avoid any conflicts between Pmodes of units (they may both want to encrypt the SOAP Body, but with different keys), and can use existing WS-Security modules (perhaps configured using WS-Security policy) with no or minimal changes. This means just one Signature which (if it is to sign the payloads) signs all payloads, not just some. This greatly simplifies the bundling protocol (and people on the TC have been stressing simplification, so I guess this is important). At ebMS level, we have access to the Pmodes of the individual user message units. So to sign the receipt, we can use different keys, if the Pmodes specify different keys. The key requirement for non-repudidation is that the UserMessage and its payloads are covered by the receipt signature. For ease of implementation (and ease of implementation is a requirement), an implementation may just want to reuse the ds:References from the received message (validated by the WS-Security module), instead of re-hashing the relevant parts (and finding out what those parts are). Since the WS-Security module may have signed more than just the parts, the receipt may include more than what is strictly needed. The ebBP receipt has references to all parts and their hashes, and they are included in the signature, so my assumption is that this is a valid receipt. Pim -----Original Message----- From: sander@fieten-it.com [mailto:sander@fieten-it.com] Sent: 20 January 2010 01:08 To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] Groups - OASIS ebXML Messaging Services Version 3.0: Part 2, Advanced Features (v46) (ebMS3-part2-V49.odt) uploaded All, in this version I edited section 2.8 to reflect the results of our discussions based on my earlier comments. One of them was that the PMode migration was not completed defined. While editing I found it is more logical to first define the general concept of PMode units and the requirements on their alignment and then explain how to migrate. Therefore I changed the order of sections 2.8.2 and 2.8.3. Current section 2.8.3 on migration also still needs to be completed. I was also wondering if it should be in the spec altogether as it is more an informative section than a normative one. Maybe it is better moved to an appendix? In this version I also made some editorial changes to section 2.9 and added some question / comments on sections 2.9 till 3.2 which I repeat below. Regards, Sander 2.9: In this section WS-SecureConversation is mentioned several times and also new PMode parameters are defined for it. WS-SecureConversation is however not mentioned in the Core spec. So it seems out of scope for ebMS V3. Why is it then introduced here in the context of multi-hop? When it is needed do the new PMode suffice to complete configure WS-SecureConversation? 3.2.1: On line 1839 (changes shown) I assume wsu:Timestamp should be wsu:Timestamp/wsu:Created ? To me the intention of the list on how a one-way user message can be bundled with another message (lines 1845-1850) is unclear. It seems that the message can be bundled with any message flowing in the same direction. Also why is this list limited to one-was user messages? Also the statements on lines 1851-1853 are not specific to bundling and I don't see what their relevance is here. 3.2.2: Which PMode is intended in the second bullet on the configuration of receipts? Based on the remark on non-repudation of receipt above the bullets I would assume the PMode governing the message unit (not necessarily the PMode of the primary unit). If the receipt covers more than the original message is it then still a valid receipt? When the configuration of the primary PMode is used to sign the receipt and the certificates of the primary PMode and the secondary PMode differ, is the receipt still a valid receipt? -- Mr. Sander Fieten The document revision named OASIS ebXML Messaging Services Version 3.0: Part 2, Advanced Features (v46) (ebMS3-part2-V49.odt) has been submitted by Mr. Sander Fieten to the OASIS ebXML Messaging Services TC document repository. This document is revision #19 of ebMS3-part2-V32-JD.odt. Document Description: View Document Details: http://www.oasis-open.org/committees/document.php?document_i d=35993 Download Document: http://www.oasis-open.org/committees/download.php/35993/ebMS 3-part2-V49.odt Revision: This document is revision #19 of ebMS3-part2-V32-JD.odt. The document details page referenced above will show the complete revision history. PLEASE NOTE: If the above links do not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser. -OASIS Open Administration
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]