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-39) 5.1.4 Use of wsu:Id and id in the eb:Messaging element for signature references

     [ https://issues.oasis-open.org/browse/EBXMLMSG-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sander Fieten updated EBXMLMSG-39:

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

> 5.1.4 Use of wsu:Id and id in the eb:Messaging element for signature references
> -------------------------------------------------------------------------------
>                 Key: EBXMLMSG-39
>                 URL: https://issues.oasis-open.org/browse/EBXMLMSG-39
>             Project: OASIS ebXML Messaging Services TC
>          Issue Type: Improvement
>          Components: AS4 Profile
>            Reporter: Theo Kramer
> 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.

This message was sent by Atlassian JIRA

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