RE: [wss] More SwA Comments

["Blake Dournaee" <blake@sarvega.com>]

Jerry,

I agree with you on the attachment being opaque, this makes things much
simpler.

I do have a further question about SOAP versioning. The SwA document is
quite dated (2000), and it sounds like MTOM has superseded the SOAP
Attachment Feature (although this is not explicit in the MTOM
specification).

Supporting the SwA W3C Note is simple, but what changes have to be made to
support SOAP v1.2? Do any changes need to be made to our SwA profile?

I am concerned that the SwA profile that we (read: Frederick!) are writing
is only going to be seen as narrowly applicable due to its emphasis on SwA
and not the Attachment Feature or MTOM.

Thanks,

Blake Dournaee
Senior Security Architect
Sarvega, Inc.



-----Original Message-----
From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com] 
Sent: Tuesday, July 13, 2004 8:18 AM
To: Blake Dournaee; wss@lists.oasis-open.org
Subject: Re: [wss] More SwA Comments

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