Re: [wss] More SwA Comments

[Jerry Schwarz <jerry.schwarz@oracle.com>]

At 01:04 PM 7/12/2004, Blake Dournaee wrote:
>All,
>
>1. The SwA profile specifically targets "W3C Note, "SOAP with Attachments",
>11 December 2000", yet there is also the SOAP Attachment Feature
>(http://www.w3.org/TR/soap12-af/) for SOAP v1.2. Does the profile intend to
>support this as well since we make the claim of SOAP version independence on
>line 95? If we don't intend to support the SOAP Attachment Feature with this
>SwA profile, should we remove the version independence statement?

I'm pretty sure that we did not intend to cover the "SOAP Attachment 
Feature" when we wrote the original submission.  It's unclear to me whether 
SOAP with attachments is still allowed when SOAP 1.2 is being used.  If it 
is then I think the current discussion is correct.

>2. While we mostly think of attachments as opaque binary blobs, I have seen
>several cases where the attachments are XML. Should we make the statement
>that this SwA profile views any XML attachments as opaque? This would limit
>the applicability of the profile in cases where we are targeting an XML
>sub-document within an attachment. That is, signing some child element
>buried in some XML that happens to be an attachment.

I think we should continue to consider the attachment as opaque. If the 
application wanted to treat the attachment as part of the body they could 
have.  I worry that if we start creating mechanisms to look into the XML in 
an attachment we'll be inventing mechanisms for treating the attachment as 
a part of the SOAP Envelope which is beyond what we should be doing.


>I believe that for the sake of clarity we should make statement about this
>use-case. If we want to allow visibility into XML documents that happen to
>be attachments (by visibility, I mean signing), we should add a clarifying
>remark about how to go about this somewhere around line 203. E.G. Use XML
>Signature transforms/filters to select the element(s) to sign.
>
>3. Line 108, we should define MTOM.
>
>4. Line 133 still refers to Content-Location
>
>5. Line 160 we should make a clarification regarding "canonicalization" so
>readers don't' confuse this with Canonical XML. We should make a statement
>about how an attachment is to be canonicalized when it is XML (if it is
>opaque, we don't want implementers running it through C14N mistakenly).
>
>Regards,
>
>Blake Dournaee
>Senior Security Architect
>Sarvega, Inc.
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of 
>the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.