[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Proposed text on C14N
Merlin The SAML token may contain its own digital signature. A signed SAML token can then be placed in the SOAP header and the token signed. It appears from the discussions that WS-Security has a number of different scenarios, for some of which inclusive is correct or safer, others for which exclusive is correct or safer and maybe some for which neither is correct or safer. Should we try to delineate the common scenarios and the correct or safer cononicalization to use for each? Don -----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com] Sent: Friday, August 29, 2003 4:58 PM To: Rich Salz Cc: firstname.lastname@example.org Subject: Re: [wss] Proposed text on C14N ... >I believe we should recommend EXC-C14N. It's designed to handle the >case of xml being wrapped, which is what we're talking about here -- XML >document being put inside a SOAP message, and being secured. Its problems >can be avoided by judicious avoidance of QNAMES as data; that is generally >something the application can address. If we expect most SOAP and WS-Security >libraries to be generic toolkits, as opposed to custom applications written >by application developers, then we cannot expect them to have such fine-grain >control over the namespace declarations used by the SOAP framework, and >therefore XML-c14n will not be viable. I disagree with your characterization of this as an example of what exc-c14n is designed for. Exc-c14n is for securing items and *then* placing them into new XML documents. We are placing items into XML documents and *then* securing, for which inclusive is safer, in that it does not need the close coupling of application to security module. ... Merlin ---------------------------------------------------------------------------- - The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept for Content Security threats, including computer viruses. http://www.baltimore.com 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 .