RE: [ebxml-msg] a bi-partisan proposal

["David RR Webber \(XML\)" <david@drrw.info>]

Pim,

I not clear that what you are saying is more involved than what Jacques was originally proposing.

What I think I'm hearing as the simplest way forward is to support WS-RM as a delivery mechanism that would be transparent to the sender and receiver.

In other words - our ebMS headers are all that the participants need to complete - and then intermediaries may deliver on one or more hops via WS-RM - but that would be handled by those middle processes that would use the information in the ebMS packaging to enable WS-RM aware steps.

This means we just need to ensure ebMS packaging supports WS-RM - and keeps our specification clear and simple.

DW

> -------- Original Message --------
> Subject: RE: [ebxml-msg] a bi-partisan proposal
> From: "Pim van der Eijk" <pvde@sonnenglanz.net>
> Date: Wed, February 13, 2008 10:04 am
> To: "'Durand,  Jacques R.'" <JDurand@us.fujitsu.com>, 
> <ebxml-msg@lists.oasis-open.org>
> 
> Hello Jacques,
>  
> If WS-Reliability is considered as an option, could it provide end-to-end
> reliable messaging in situation 2 (b) too? Assuming a constraint that the
> reliable messaging headers must be piggy-backed with ebMS headers (assuming
> routing is based on these ebMS headers). When the sender knows which
> messages will end up at the same MSH (even if it does not know which
> particular MSH), it could send these messages as a group. If it does not
> even know this, it could use groups of cardinality one, functionality that
> ebMS 2.0 reliable messaging provides today. Security would be preserved too.
> 
>  
> When end-to-end reliable messaging is not used, perhaps we need to consider
> two separate wsse:Security blocks to secure the exchange:
> 1: One that signs the complete SOAP with attachments message, including any
> WS-A and WS-RM headers, targeted at the next MSH.
> 2: A second header that signs (and encrypts) only the ebMS 3.0 header and
> all payloads, targeted at the ultimate receiver MSH.
> An intermediary would remove the first wsse:Security header block and
> re-sign the message. The second wsse header, the ebMS 3.0 header and all
> payloads would be copied. In this scenario, the intermediary can forward
> messages in different sequences, not necessarily to the same ultimate
> receiving MSH, and it can even deliver some messages locally. An
> intermediary needs sequences to deliver to its associated endpoints and for
> any other intermediaries. Each intermediary is an end-point for WS-A and
> WS-RM processing, except for the special ACK "relaying" functionality. 
>  
> I know proposing a second header violates the requirement that endpoints
> should not have to behave differently to support intermediaries, but we need
> to balance that against the requirement of end-to-end security. 
>  
> Pim
>  
>  
> 
> 
>   _____  
> 
> From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] 
> Sent: 13 February 2008 05:07
> To: ebxml-msg@lists.oasis-open.org
> Subject: [ebxml-msg] a bi-partisan proposal
> 
> 
> Here is a bi-partisan proposal for a change ;-)
>  
> 1. The core of an "Intermediary role" specification should primarily focus
> on such functions as store-and-forward, bridging MPCs, rules for bridging
> MEPs e.g. allowing a received pushed message to be pulled, etc.
> - The routing function has to be assumed, but can remain unspecified, as it
> may depend on various header data anyway.
> - the RM function can be largely ignored when specifying the above.
>  
> 2. Reliability function: a couple of options should be specified.
>  
> (a) Because there will be multi-hop configurations where the Sender knows
> enough about the ultimate receiver endpoint so that routing is not an issue
> even for RM signals,  the end-to-end RM sequence should be an option. Note
> that this option is straightforward for conformance profiles that make use
> of WS-Reliability (no RM signals besides Acks). When using
> WS-ReliableMessaging, it will require routing support for RM signals (e.g.
> use of WSA, or other means TBD).
> This option is the only "fully transparent" end-to-end RM (e.g. for
> security) and this alone justifies to support it although not possible in
> all multi-hop configurations dues to routing constraints. It is also very
> straightforward in terms of itnermediary conformance - once the routing is
> resolved.
>  
> (b) Because there will be multi-hop configurations where the routing of RM
> signals cannot be done e.g. to establish a stable RM sequence between two
> endpoint MSHs (e.g. because of too much dynamics on resolving MSHs even if
> partners are known, or because security issues require to "hide" a portion
> of the cloud) then end-to-end RM sequences cannot be established. In that
> case, an advanced intermediary profile will support RM sequences "bridging",
> so that end-to-end delivery assurance is still possible at least for
> "At-Least-Once", "At-Most-Once" and "Exactly-Once" delivery. This bridging
> can involve some Ack relaying techniques that need to be specified so as to
> depart as little as possible from standard RM module behavior.
>  
> Clearly, some multi-hop topologies might combine both (a) and (b). E.g. the
> I-cloud includes a "hidden" portion that has a well-known "gatekeeper"
> intermediary. Regardless of how many intermediaries are involved between a
> Sender endpoint MSH and a "hidden" ultimate Receiver MSH, it is possible to
> use a single RM sequence from Sender to Gatekeeper, and a single RM sequence
> from Gatekeeper to ultimate Receiver, while reducing the RM sequence
> bridging to the Gatekeeper only (all other intermediaries of the I-cloud
> being "transparent"). A non-transparent Gatekeeper would make sense anyway
> as  it is possible that the QoS on the hidden I-cloud is different (e.g. a
> VPN), so some Security processing may need to take place on the Gatekeeper,
> e.g. validating a sig on the RM headers that are removed, or removing
> encryption.
>  
> Hope that may relieve the deadlock... or provide enough wiggle room to move
> one step further.
>  
> Jacques