[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] SwA Interoperability Document
Mike, When you say you want to treat XML in attachments as text, are you essentially saying that we're not going to allow any *profile-specific* means of interpreting the attachment as an XML node-set (info-set)? That is, the attachments are *opaque* in this sense? What do others think? This definitely limits the scope of what can be targeted to participate in a signature, but this may be a good thing. I think we need to address this somehow in the profile, because people will have questions about it. Blake Dournaee Senior Security Architect Sarvega, Inc. -----Original Message----- From: Michael McIntosh [mailto:mikemci@us.ibm.com] Sent: Monday, July 12, 2004 2:54 PM To: Blake Dournaee Cc: wss@lists.oasis-open.org Subject: Re: [wss] SwA Interoperability Document "Blake Dournaee" <blake@sarvega.com> wrote on 07/12/2004 05:23:29 PM: > Hello Everyone, > > It's time to start writing the interop document for the SwA profile. I'll be > heading this up and want to gather feedback for the scenarios that we would > like to have. > > As of now, I'm proposing the following scenarios: > > 1. Signed Attachments > (a) Sign an opaque binary attachment using "Attachment-Complete" > (b) Sign an opaque binary attachment using "Attachment-Content-Only" > > 2. Encrypted Attachments > (a) Encrypt an opaque binary attachment using the "Attachment-Complete" > > URI on <EncryptedData> and the "ContentOnlyCipherText" transform > (b) Encrypt an opaqye binary attachment using the "Attachment-Content- > Only" URI on <EncryptedData> and the "ContentOnlyCipherText" transform > > 3. Signed and Encrypted Attachment > (a) Sign, then encrypt an attachment. For the signing operation use > "Attachment-Complete", for the encryption operation, choose > "Attachment-Complete" as well. > > *4. Signing a child element within an attachment that happens to be XML. > This scenario will involve the use of an XPath transform at a minimum. > > * What do people think of this scenario? I believe that it goes outside the > bounds of the SwA profile, but believe that it is a good exercise for > implementations. Unless we make a statement about all XML attachments being > opaque, it won't be long before someone may want to do this. I'd like to treat XML in attachments as text. I do not think we want to have to allow XPath expressions in the root part (SOAP Envelope) to evaluate to XML inside another part. > > Please send me your comments and ideas for this interop; we can talk more on > the call tomorrow. > > Kind 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. > 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 .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]