Re: New Attachments Issues

Marc, I think your formulation is precisely what I'd say. 8-)

I don't think we ever wanted to consider security mechanisms visible to
the application that would be aware of any optimizations not visible to
the application, like the optimization of binary data in SOAP messages.
I thought the expectation was that dig-sig or encryption would work on
canonical base64 representation of the data. There can still be some
optimizations in the implementations, e.g. only do the base64 encoding
on the fly for signature computation, never store the actual full base64
version of the data. Base64 encoding is cheap and if the signature code
can consume a stream, the cost of base64 encoding will be lost in the
cost of computing the signature, I believe (and somebody else has
mentioned this before me, too).

Best regards,

                   Jacek Kopecky

                   Senior Architect
                   Systinet Corporation
                   http://www.systinet.com/






On Tue, 2003-06-10 at 16:35, Marc Hadley wrote:
> So, to paraphrase, you would say that:
> 
> (1) We DO NOT expect intermediaries to preserve what is serialized as 
> attachments and what is serialized inside the SOAP envelope.
> 
> (2) The binding determines which nodes to serialize as attachments in 
> an implementation specific manner.
> 
> That's certainly a coherent answer to the two issues.
> 
> Your proposed answers probably have some implications for the set of 
> security technologies we can apply to messages containing attachments, 
> e.g. I expect it would prevent use of S/MIME or PGP-MIME. It also means 
> that digital signatures must always be calculated on the text data 
> representation of attachments and verified using the same - i.e. even 
> if you use attachments to optimize the transfer, if you are using XML 
> security that includes the attachment data then you always need to 
> compute the base64 transform at both sender and receiver.
> 
> Marc.
> 
> On Tuesday, Jun 10, 2003, at 07:46 US/Eastern, Jacek Kopecky wrote:
> 
> > As we're only talking about optimization of transfer of binary data
> > (we're not yet talking about the other aspects of PASWA, like
> > swa:Representation), it is not critical from our point of view that the
> > optimization be preserved across intermediaries (1) or that it be done
> > at all (2). However, I do think we should say something, so I prefer
> > option (ii) below - that we say your two questions are answered in
> > implementations in an implementation-specific way.
> >
> > It is important that whatever we produce from PASWA emphasizes the fact
> > that we're providing a possible optimization of binary data transfer 
> > and
> > how it may be particularly useful with the other stuff like
> > swa:Representation.
> >
> > Best regards,
> >
> >                    Jacek Kopecky
> >
> >                    Senior Architect
> >                    Systinet Corporation
> >                    http://www.systinet.com/
> >
> >
> >
> >
> >
> > On Fri, 2003-06-06 at 18:25, Marc Hadley wrote:
> >> All,
> >>
> >> Following the resolution of issue 429[1], I'd like to raise the
> >> following new issues:
> >>
> >> 1: "What are the semantics of attachments w.r.t. SOAP intermediaries.
> >> E.g. do we expect intermediaries to preserve what is serialized as
> >> attachments and what is serialized inside the SOAP envelope."
> >>
> >> 2: "How does the binding determine which nodes to serialize as
> >> attachments ?"
> >>
> >> Amongst the many possible answers, the following spring immediately to
> >> mind:
> >>
> >> (i) We don't specify that.
> >> (ii) An implementation specific mechanism (similar to (i) but we
> >> explicitly say so).
> >> (iii) Its triggered by something in the infoset - if so, what.
> >>
> >> Thanks,
> >> Marc.
> >>
> >> [1] http://www.w3.org/2000/xp/Group/xmlp-issues#x429
> >>
> >> --
> >> Marc Hadley <marc.hadley@sun.com>
> >> Web Technologies and Standards, Sun Microsystems.
> >
> >
> --
> Marc Hadley <marc.hadley@sun.com>
> Web Technologies and Standards, Sun Microsystems.

Received on Tuesday, 10 June 2003 10:57:04 UTC