Re: One-way MEP with security

IIRC, the action was concerning use of in-message security (as an  
example of a SOAP-based feature) with a multicast one-way MEP.  
However, the SOAP-based security example you describe below doesn't  
feature a multicast MEP but rather multiple instances of a unicast  
MEP. The claim that:

> this is an example of the one-way MEP, in which there happens
> to be more than one receiver.

mischaracterizes MEPs as being end-to-end but in the SOAP binding  
framework MEPs are hop-by-hop. As a result I don't think this example  
really serves to explore the interactions it was intended to.

Marc.

On Oct 26, 2006, at 9:58 AM, David Hull wrote:
>
> I have an action to propose text explaining possible subtle  
> interactions
> between the one-way MEP and, say, a SOAP security mechanism which
> encodes a message to a receiver with that receiver's public key, in
> other words, one which, given a single sent SOAP message, produces a
> different SOAP message for each recipient.
>
> On further reflection, I'm not convinced that anything subtle is  
> going on.
>
> First, consider a scenario where security is handled outside SOAP.  I
> believe that XMPP can provide such an example.  In this case:
>
>     * The sender sends a plaintext SOAP message
>     * The transport encrypts that message, producing a different  
> message
>       on the wire for each recipient.
>     * For each receiver, the transport decrypts that receiver's copy
>     * Each receiver receives a plaintext SOAP message.
>
> Clearly, this is an example of the one-way MEP, in which there happens
> to be more than one receiver.
>
> Now consider a scenario where security is handled within SOAP.
>
>     * The sender sends a plaintext SOAP message to an intermediary
>     * The intermediary encrypts that message, producing a different  
> SOAP
>       message for each recipient, which it then sends out.
>     * For each receiver, an intermediary receives an encrypted SOAP
>       message and produces a plaintext SOAP message, which it sends to
>       the receiver
>     * Each receiver receives a plaintext SOAP message.
>
> Clearly, this is an example of the one-way MEP, in which there happens
> to be more than one receiver.
>
> As it happens, it also involves several other examples of the one-way
> MEP, each with a single receiver.
>
> The one-way MEP is playing a crucial role here.  It provides a  
> standard
> way to assert that each receiver receives the same plaintext message,
> whatever happens in the middle.  Put another way, it provides a  
> standard
> way to assert that the overall behavior of the two systems is the  
> same.
> You can use the underlying transport's security if it's available.  If
> it's not, or if you otherwise choose not to, you can handle security
> end-to-end using SOAP.
>
> As far as I can tell, this is not a subtle interaction between  
> security
> and the one-way MEP.  It is simply layering.
>
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.