ebMS3-part2-V50.odt Details

Document Details     TC Member Document View
Title ebMS v3.0: Part 2, Advanced Features (v50)
Name * ebMS v3.0: Part 2, Advanced Features (v50) (571K)
Description No description provided.
Group OASIS ebXML Messaging Services TC
Folder Proposals
Submitter Mr. Pim van der Eijk
Date Submitted Tuesday, 26 January 2010 04:58pm
Document State Draft (A preliminary unapproved sketch, outline, or version.)
Access This document is visible to OASIS ebXML Messaging Services TC and shared with:
  • OASIS Open (General Membership)
  • General Public

Document Revisions
Name # State Submitter Date Action
35
Draft
Mr. Jacques Durand
2010-06-28
34
Draft
Mr. Pim van der Eijk
2010-06-26
33
Draft
Mr. Pim van der Eijk
2010-06-20
32
Draft
Mr. Jacques Durand
2010-06-07
31
Draft
Mr. Jacques Durand
2010-06-01
30
Draft
Mr. Pim van der Eijk
2010-05-29
29
Draft
Mr. Pim van der Eijk
2010-05-24
28
Draft
Mr. Pim van der Eijk
2010-04-25
27
Draft
Mr. Jacques Durand
2010-04-19
26
Draft
Mr. Pim van der Eijk
2010-03-29
25
Draft
Mr. Jacques Durand
2010-03-17
24
Draft
Mr. Jacques Durand
2010-03-16
23
Draft
Mr. Jacques Durand
2010-02-19
22
Draft
Mr. Pim van der Eijk
2010-02-06
21
Draft
Mr. Pim van der Eijk
2010-01-31
20
Draft
Mr. Pim van der Eijk
2010-01-26
This doc
19
Draft
Mr. Sander Fieten
2010-01-19
18
Draft
Mr. Sander Fieten
2010-01-05
17
Draft
Mr. Pim van der Eijk
2009-12-13
16
Draft
Mr. Pim van der Eijk
2009-12-06
15
Draft
Mr. Sander Fieten
2009-11-25
14
Draft
Mr. Pim van der Eijk
2009-11-17
13
Draft
Mr. Pim van der Eijk
2009-09-28
12
Draft
Mr. Pim van der Eijk
2009-09-13
11
Draft
Mr. Pim van der Eijk
2009-09-09
10
Draft
Mr. Sander Fieten
2009-09-01
9
Draft
Mr. Pim van der Eijk
2009-08-25
8
Draft
Mr. Jacques Durand
2009-08-18
7
Draft
Mr. Sander Fieten
2009-06-09
6
Draft
Mr. Pim van der Eijk
2009-06-01
5
Draft
Mr. Jacques Durand
2009-05-27
4
Draft
Mr. Sander Fieten
2009-05-26
3
Draft
Mr. Pim van der Eijk
2009-05-24
2
Draft
Mr. Pim van der Eijk
2009-05-19
1
Draft
Mr. Jacques Durand
2009-04-29
0
Draft
Mr. Jacques Durand
2009-04-28

Comments  
Subject & Text Submitter Date Action
Initial comment by submitter
Accepted all changes in previous version before making any changes.

2.4.5

This used to be a header of a separate section, and is now a header
again.

Added a note that the Icloud wsa:To must also be understood by
intermediaries and reference to 3.7.1 (discussion point).

Renamed Pmode[1].AddActorOrRoleAttribute to
Pmode[1].Protocol.AddActorOrRoleAttribute since it is in the
Protocol group.

2.6.2

Case (3) talked about wsa:Action where wsa:Address was intended.


2.6.6

In the discussion on message expiration, added a reference to
wsu:Timestamp/wsu:Expires.

2.7.2

Talked about wsa:Action where wsa:Address was intended.

2.7.3.1

Important change to review:

The wsa:To is there to tell ebMS intermediaries to route based on
the reference parameter. So they both should have the role attribute ?

To treat all WS-Addressing headers consistently, I'm treating the
wsa:Action the same way? But it is never used for routing.

If these changes are not reversed, appendices D-F also need to be
updated.

2.7.3.2

Added a reference to 2.8.1.2

2.8.1.2

Introducing a P-Mode parameter to allow partners to agree on a
non-default value for wsa:Action.

3.7.1

3.2.1

Several textual improvements based motivated in:
http://lists.oasis-open.org/archives/ebxml-msg/201001/msg00013.html

3.2.2

Third bullet:

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 (implementation of) the bundling protocol.


As the receipts are generated per unit at the ebMS level, in fact it
should be the secondary unit's configuration that is used (not the primary
unit). At the ebMS level (after unbundling) all information
related to bundling is lost and only the units are available.

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.

4.2

Renamed Pmode[1].AddActorOrRoleAttribute to Pmode[1].Protocol.AddActorOrRoleAttribute

4.3

Added reference to 2.8.1.2 (wsa:Action with explicit value).
Mr. Pim van der Eijk
2010-01-26
---