Are XML Attachments Opaque or Not?

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

Frederick, All -

It looks like this latest revision (8) of the WSS SwA profile is still
making references to Canonical XML as applied to XML attachments (Lines 284,
Lines 254-257, 159-160).

What this is telling me is that the SwA profile isn't considering XML
documents that happen to be attachments as opaque, but allowing further
"reach" of this profile into these node sets. At least we're not being clear
about where the profile stops.

Please correct me if I am wrong, but I had thought we agreed that the
profile *would* indeed consider XML that happens to be an attachment as
opaque and not allow further reach into these XML documents.

My real question here is regarding those implementations and use cases that
which to sign a *subdocument* of an attachment that happens to be XML. We
should either disallow this or allow it and profile it.

Below is the trail that I started a month or so ago on this issue.

Please let me know what everything thinks, perhaps the decision was reversed
and I missed it.

Blake Dournaee
Sarvega, Inc.

-----Original Message-----
From: Blake Dournaee [mailto:blake@sarvega.com] 
Sent: Tuesday, July 13, 2004 9:06 AM
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:
....

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