One-way MEP, multicast and encryption: A detailed example

Here is an example of layering bindings of the one-way MEP to produce
useful behavior.  The layering is simple:  Layer fan-out over secure
encryption over a transport binding.  The explanation of how it works
and what it means in terms of the SOAP model is verbose, but not
complex.  It's just plug-and-chug with the same basic concepts over and
over.  That gives me good confidence that it can be realized using
software.  My major takeaway from this: Intermediaries and the SOAP
processing model can provide layering.

------------------------------------------------------------------------

In the model we've been discussing, a sender of a one-way message
essentially hands (destination, message) to a binding supporting the
one-way MEP.  The binding is responsible for delivering the message to
zero or more receivers.  Delivering essentially means populating
(sender, message) at the receiver, where the message at the receiver
must be identical to the message at the sender.  Otherwise there is a
failure, which may even be reported. From the point of view of the SOAP
processing model, there is a separate message path from the sender to
each receiver.  The binding may provide further information about the
nature of said paths.

Suppose a sender wishes to send a message to some distribution list.  As
a quality-of-service parameter, it wants to ensure that the message is
encrypted according the the requirements of the receivers.  These
requirements may differ from receiver to receiver.

There are several ways to accomplish this.  Here is one, chosen for
illustrative purposes.  It requires the following bindings of the
one-way MEP:

    * One or more transport bindings.  These take a SOAP message and a
      destination, render it onto the wire, deliver it and recover the
      SOAP infoset at the receiving end.  For each receiver, there is a
      single-hop message path from the sender, with no intermediaries.
    * An secure binding.  This binding requires a set of encryption
      parameters (algorithm, key, etc.) and makes use of an underlying
      non-secure binding, which must support the one-way MEP.  The set
      of the receivers is the same as for the underlying binding (for
      the sake of this example we can assume the underlying binding is
      unicast, though it need not be).  For each receiver, the message
      path consists of
          o A one-way from the sender to an encrypting intermediary. 
            This intermediary produces, according to the parameters it
            was given, an encrypted SOAP message from the plaintext SOAP
            message (i.e., some of the headers of the encrypted message
            may be readable, but the bulk will be gibberish).
          o A one-way using the underlying binding, from the encrypting
            intermediary to a decrypting intermediary, which produces a
            plaintext SOAP message from the encrypted one.  Decryption
            must be the inverse of encryption.  That is, this process
            must reproduce the original message.
          o A one-way from the decrypting intermediary to the receiver.
          o As decryption is the inverse of encryption, this chain
            satisfies the MEP requirement that the received message be
            identical to the sent message.
    * NOTE: If the underlying binding supports multicast, each receiver
      will (by definition) receive an identical encrypted message in the
      middle hop.  To provide per-receiver parameters, we need ...
    * A fan-out binding.  This binding makes use of one or more
      underlying bindings, which must support the one-way MEP.  The set
      of receivers is the union of those for the destinations found in
      the fan-out process (again for the sake of the example, we can
      assume that this underlying bindings are unicast, though again
      they need not be).  For each receiver, the message path consists of
          o A one-way from the sender to a fan-out intermediary.  This
            intermediary takes (destination_1 , message) and from the
            destination_1 determines a set of (destination_2 , binding)
            pairs.
          o A one-way from the intermediary to the receiver, using the
            binding determined for that receiver's destination_2 .  The
            message for this hop is identical to the message for the
            first hop, ensuring identity from sender to receiver.
    * For purely technical reasons, a "no-op" binding which just
      forwards (destination, message) to the next hop.  The set of
      receivers contains (only) the sender for the next hop.

Putting it together:  The sender sends a message using the fan-out
binding to a multicast destination.  The intermediary in the fan-out
binding must know the actual receivers (or more accurately, what
destination_2 addresses to use to reach them), and the encryption
parameters for each (that is, for each destination_2 ).  Note that
/someone/ at the sending end has to know this information.  The binding
for each destination_2 is the secure binding with the given parameters. 
The underlying binding for the secure binding is the actual transport
binding for reaching that destination.  The receivers will be using the
same encrypted binding in the same way.  Again, note that the receivers
have to know to decrypt, so again this is not an additional requirement.

This implements a "secure multicast" binding of the one-way MEP using
the bindings above.  The set of receivers is the union of the receivers
for each destination_2 in the fan-out.

For each receiver, the full message path consists of

   1. A one-way from the sender to the fan-out.
   2. A one-way from the fan-out to the encrypting intermediary
   3. A one-way from the encrypting intermediary to the decrypting
      intermediary
   4. A one-way from the decrypting intermediary to the receiver.

As we are implementing the one-way MEP we have to assure ourselves that
the message received is the same as the message sent.  This is
straightforward:

    * Steps 1, 2 and 4 use the no-op binding, which works by definition.
    * Step 3 uses a transport binding, which works by construction.
    * Steps 2, 3 and 4 together constitute a one-way under the secure
      binding, which works because decryption is the inverse of
      encryption (and because step 3 works, and because equality is
      transitive).
    * Steps 1 through 4 together constitute a one-way because 1 does and
      steps 2 through 4 together do (and because equality is transitive).