RE: [wss] Proposed text on C14N

["Don Flinn" <flinn@alum.mit.edu>]

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: merlin@baltimore.ie [mailto:merlin@baltimore.ie]
Sent: Friday, August 29, 2003 4:58 PM
To: Rich Salz
Cc: wss@lists.oasis-open.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
.