Re: PASWA, Include and Protocol Bindings

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

I'd say all of these are reasonable (although #2 makes me wonder whether
some people think that the parent EII of an Include is REQUIRED to carry
xmime:MediaType, which I don't think it a good thing). Serializing binary
data into attachments is an optimisation, and therefore must be
functionally equivalent to base64'ing the data; as a result, it's up to
each node to make these decisions.

I'd add to the list that this information might be carried in a header,
which brings its own tradeoffs; it's likely to be more brittle (especially
if it uses XPath; perhaps associating types with QNames would be more
resilient), but isn't as intrusive into the body.


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

An alternative is to use a signature algorithm that (perhaps selectively)
operates on the value space of the content, rather than the lexical space.
This sidesteps the problem by making the attachment mechanism transparent,
as intended.


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

That would be one way of hinting for reserialization. I'm somewhat wary of
mandating a single way of doing this, as I think there are a variety of
use cases, each with its own requirements.

Cheers,

Received on Thursday, 8 May 2003 13:59:01 UTC