RE: PASWA, Include and Protocol Bindings

Marc,

I think these issues are interesting ( and tractable, your posited
attribute is one solution ). We should add them to the (currently
imaginary) issues list ;-) 
More inline.

Gudge

> -----Original Message-----
> From: Marc Hadley [mailto:Marc.Hadley@Sun.COM] 
> Sent: 08 May 2003 17:09
> To: Martin Gudgin
> Cc: noah_mendelsohn@us.ibm.com; Mark Nottingham; xml-dist-app@w3.org
> Subject: 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.
> 

It seems to me that, per xmldsig, the xmldsig:SignedInfo element would
contain the URI of the C14N algorithm used. This would indicate whether
chars or bytes were used as input to signature calculation. This would
give C and D (or anyone else) enough info to perform the correct
calculation.

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

Again, the xmldsig:SignedInfo provides the context to get the calcs
right. I agree that D could add unnecessary overhead for E.

> 
> 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 Wednesday, 14 May 2003 11:10:59 UTC