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