RE: [wss] More SwA Comments

[<Frederick.Hirsch@nokia.com>]

MTOM will not require use of this profile - with MTOM attachments
transparently benefit from
SOAP Message Security. 

So is it correct to say this profile is limited to SOAP 1.1 and SwA. 

Regards, Frederick

Frederick Hirsch
Nokia

> -----Original Message-----
> From: ext Blake Dournaee [mailto:blake@sarvega.com] 
> Sent: Tuesday, July 13, 2004 12:06 PM
> To: 'Jerry Schwarz'; wss@lists.oasis-open.org
> Subject: RE: [wss] More SwA Comments
> 
> 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/leav
e_workgrou
> >p.ph
> p.
> 
> 
> 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.
> 
>