Re: PASWA, Include and Protocol Bindings

Following some discussion on this weeks telcon and some private 
discussion with Gudge I'd like to try to capture a couple of the issues 
I see in the current formulation. The following assumes an explicit 
goal of minimizing base64 encoding in implementations.

On Wednesday, May 7, 2003, at 14:34 US/Eastern, Martin Gudgin wrote:
>
> Given that the Infoset is a data model, it is difficult to distinguish
> between 'logical' and 'actual' inclusion at that level. Certainly at 
> the
> serialization level, a SOAP stack that implements PASWA would serialize
> binary data as binary bits. However, consider the following case:
>
> A -> B -> C ->D -> E
>
> where C does NOT understand PASWA. The serialization stream would be as
> follows:
>
> A -PASWA-> B -SOAP1.2HTTP-> C ->SOAP1.2HTTP-> D -PASWA-> E
>
> So, the ultimate receiver ( E ) gets a PASWA message, but along the 
> way,
> it was at some point serialized accordings to the HTTP binding we have
> in SOAP 1.2 today.
>

Some questions:

1) With the current data model, how does D decide which parts of the 
SOAP message to serialize as attachments ? Some possible answers are:

- All instances of base64 typed data (assuming I have a schema, which 
is not necessarily the case for an intermediary, or I can spot base64 
encoded data another way).
- All instances of base 64 data whose parent EII contains a 
xmime:MediaType attribute.
- All instances of base64 typed data that is larger than some threshold 
size.

2) If A wants to incorporate message security including the attachments 
then it has a couple of obvious options:

- Generate signatures based on the base64 encoded version of the data 
(requires base64 encoding step)
- Use an attachment/xninc:Include aware C14N algorithm that allows 
signing of the raw attachment octets (base64 encoding not required).

If A uses the latter case, how do C or D determine which instances of 
base64 encoded data to decode prior to signature verification ? This is 
related to the problem described in 1) above.

If A uses the former case then D better be careful about which parts of 
the message it turns into attachments otherwise it could make 
additional work for E base64 encoding attachments prior to signature 
verification.

A solution to this would be addition of some marker (e.g. an attribute) 
to the parent EII of an xbinc:Include when performing the literal 
inclusion. This would maintain the information that 'this stuff was an 
attachment in a previous hop' that would otherwise be lost in the 
current formulation.

Marc.

--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Thursday, 8 May 2003 12:10:36 UTC