Re: [wss] More SwA Comments

[Michael McIntosh <mikemci@us.ibm.com>]

"Blake Dournaee" <blake@sarvega.com> wrote on 07/12/2004 04:04:34 PM:

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

I'd like to treat non-root MIME Parts containing XML as text. We don't want
to have to deal with XML Canonicalization/Namespaces/etc.

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