Uploaded image for project: 'OASIS ebXML Messaging Services TC'
  1. OASIS ebXML Messaging Services TC
  2. EBXMLMSG-39

5.1.4 Use of wsu:Id and id in the eb:Messaging element for signature references

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Component/s: AS4 Profile
    • Labels:
      None
    • Proposal:
      Hide

      Amend section 5.1.4 profiling rule (b) as follows

      AS4 MSH implementations are REQUIRED to include the entire eb:Messaging SOAP header block and the (possibly empty) SOAP Body in the signature. The eb:Messaging header MUST be referenced using either the "id" attribute or the "wsu:Id" attribute.

      Show
      Amend section 5.1.4 profiling rule (b) as follows AS4 MSH implementations are REQUIRED to include the entire eb:Messaging SOAP header block and the (possibly empty) SOAP Body in the signature. The eb:Messaging header MUST be referenced using either the "id" attribute or the "wsu:Id" attribute.

      Description

      Section 5.1.4 profiling rule (b) of the AS4 profile reads as follows

      AS4 MSH implementations are REQUIRED to include the entire eb:Messaging SOAP header block and the (possibly empty) SOAP Body in the signature. The eb:Messaging header SHOULD be referenced using the "id" attribute.

      But Section 4 of the Web Servicesi Security: SOAP Message Security 1.1 (WSS 1.1) reads as follows

      " There are many motivations for referencing other message elements such as signature
      references or correlating signatures to security tokens. For this reason, this specification defines
      the wsu:Id attribute so that recipients need not understand the full schema of the message for
      processing of the security elements. That is, they need only "know" that the wsu:Id attribute
      represents a schema type of ID which is used to reference elements. However, because some
      key schemas used by this specification don't allow attribute extensibility (namely XML Signature
      and XML Encryption), this specification also allows use of their local ID attributes in addition to
      the wsu:Id attribute and the xml:id attribute [XMLID]. As a consequence, when trying to locate
      an element referenced in a signature, the following attributes are considered (in no particular
      order):

      • Local ID attributes on XML Signature elements
      • Local ID attributes on XML Encryption elements
      • Global wsu:Id attributes (described below) on elements
      • Profile specific defined identifiers
      • Global xml:id attributes on elements
      ...
      Tokens and elements that are defined in this specification and related profiles to use wsu:Id
      attributes SHOULD use wsu:Id. Elements to be signed MAY use xml:id [XMLID] or wsu:Id,
      and use of xml:id MAY be specified in profiles. All receivers MUST be able to identify XML
      elements carrying a wsu:Id attribute as representing an attribute of schema type ID and process
      it accordingly.

      All receivers MAY be able to identify XML elements with a xml:id attribute as representing an ID
      attribute and process it accordingly. Senders SHOULD use wsu:Id and MAY use xml:id. Note
      that use of xml:id in conjunction with inclusive canonicalization may be inappropriate, as noted
      in [XMLID] and thus this combination SHOULD be avoided. "

      This meaning that signature references must either be verified using the optional ebxml 'id' (of type xsd:ID) attribute in the eb:Messaging element (as defined in the ebMS3 header schema) or alternatively using the wsu:Id attribute, yet always wsu:Id for the Body element as there is no alternate ID defined for the Body element.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              theo Theo Kramer (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: