OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (EBXMLMSG-109) InclusiveNamespaces, Prefixlist

Pim van der Eijk created EBXMLMSG-109:

             Summary: InclusiveNamespaces,   Prefixlist
                 Key: EBXMLMSG-109
                 URL: https://issues.oasis-open.org/browse/EBXMLMSG-109
             Project: OASIS ebXML Messaging Services TC
          Issue Type: Bug
          Components: Core Spec
            Reporter: Pim van der Eijk

A question came up on the use of InclusiveNamespaces in exclusive XML canonicalization of signed ebMS3 messages.  In XML Exclusive Canonicalization, this element can be used to pass additional namespace definitions for namespaces that are not visibly used in the referenced XML payload. 

The ebMS3 specification does not specify whether any list of prefixes is to be applied. The examples in the current WS-Security and ebMS3 specifications do not have a prefix list.
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_core-3.0-spec-os.html#7.9.1.Digitally Signed and Encrypted ebXML Message|outline

When looking at reports from a number of AS4 products,  published at:
https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/e-SENS+AS4+conformant+solutions, and input on another product not on the list,  the reality is that some products do set this element and others don't.  when two products set the element, it is not always to the same list.   Products that do have the element set are known to interoperate with products that don't. 

Section 3.5.7 of the BSP states that:
Any SIG_TRANSFORM with an Algorithm attribute with a value of "http://www.w3.org/2001/10/xml-exc-c14n#"; MUST contain an INCLUSIVE_NAMESPACES with an PrefixList attribute unless the PrefixList is empty.

As ebMS3 or WS-Security do not specify a list of namespaces to be included,  it can be argued that the list is logically "empty" and that therefore there is no requirement for the INCLUSIVE_NAMESPACES to be present.  At the same time,  if an application wants to use it, it seems there is nothing in the specification prohibiting it from doing so.

Is anyone aware of any issues around this element?  
Do we need to add any clarification to the specification?


This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]