W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2003

Re: PASWA, Include and Protocol Bindings

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Thu, 08 May 2003 12:09:24 -0400
To: Martin Gudgin <mgudgin@microsoft.com>
Cc: noah_mendelsohn@us.ibm.com, Mark Nottingham <mark.nottingham@bea.com>, xml-dist-app@w3.org
Message-id: <6F5EE24C-816F-11D7-9596-0003937568DC@sun.com>

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:
> 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 

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 

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 Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Thursday, 8 May 2003 12:10:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:23 UTC