Title: Reliable / Duplicate / Message Order Inconsistencies
Bob,
It is completely within the purview of the ebXML-msh
specification to describe how XML DSIG should be (must be) used in a
conforming message. If the current specification attempts to redefine XML
DSIG, we should correct those errors. What you're saying implies we
shouldn't even say what XML DSIG features should be used in a conforming
message.
The current specification allows parallel running of the
"eb" and "ds" namespace handlers and doesn't say much about how errors in each
are distributed to the other. (That seems to be an implementation issue
beyond our scope.) I believe the current text allows an implementation as
you describe below except the ebXML handler should be made aware of (should be
able to query) the invocation and success of the XML DSIG
handler.
With regards to "ds" being a foreign namespace, our comments
on foreign namespaces apply only to such content within ebXML elements.
The only time we embed security data from a foreign namespace is the
ds:Reference elements in the eb:Acknowledgment. That's not handled using a
wildcard and is described as a required aspect of signing an acknowledgment
message.
thanx,
doug
----- Original Message -----
From: Miller,
Robert (GXS)
To: ebxml-msg
Sent: Monday, 10 December 2001 11:32
Subject: [ebxml-msg] ebXML Security
As
followup to my concerns about the Security section of the ebXML MSG, I offer the
following observations.
1) The
Namespace defining the Security structures in the ebXML specification is a
namespace foreign to the ebXML namespace.
2) A
conforming SOAP processor will direct processing of the security structures to
the handler for that namespace, which might not be same handler as the ebXML
namespace handler. In fact, the ebXML processor might not even be aware of
the presence and execution of a security handler.
3) End
users must be free to purchase security add-on SOAP modules independent of
ebXML module
4)
None of the text in section 4.1 that relates to the definition of specific
elements defined by the "ds" namespace can be normative, as the normative
definition of these elements is in fact provided in a document prepared by
another organization (W3).
--------------
In my
opinion,
o
- that portion of section 4.1 that addresses specific constructs defined in
the"ds" namespace must be relocated to a non-normative Appendix.
o
- the ebXML MSG specification may (and probably should) provide guidance on
the use of non-ebXML SOAP extensions (such as security).
o
- ebXML conformance can only address conformance of ebXML specific modules.
In particular, it cannot address conformance with respect to those consturcts
fgoverned by a 'foreign' namespace.
o -
a locator reference to the W3 specification(s) for security should be
provided.
Cheers,
Bob Miller
