Issue 011: WS-SX Charter XPath reqts and WS-SecurityPolicy use of XPath (5.1, 5.2) appear in conflict

Title: NEW Issue: WS-SX Charter XPath reqts and WS-SecurityPolicy use of XPath
(5.1, 5.2) appear in conflict

This has been added
to the issue list as issue 11.

http://docs.oasis-open.org/ws-sx/issues/Issues.xml#i011

 

From: Levinson,
Richard [mailto:] 

Sent: Tuesday, December 13, 2005
1:08 PM

To: 

Cc: Marc Goodner

Subject: NEW Issue: WS-SX Charter
XPath reqts and WS-SecurityPolicy use of XPath (5.1, 5.2) appear in conflict

 

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSION
THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. 

The issues coordinators will notify the list when that has
occurred. 

Protocol:
ws-sp and ws-sx charter 

   
use this link for original link to WS-SecurityPolicy:

        http://www.oasis-open.org/apps/org/workgroup/ws-sx/email/archives/200511/msg00001.html

   
to get to WS-SecurityPolicy directly:

        http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf

   
use this link to get to the Charter:

        http://www.oasis-open.org/committees/wss/charter.php

Artifact:

        policy 

Type:

        either design or
editorial depending on resolution 

Title:

        "WS-SX Charter XPath
reqts and WS-SecurityPolicy use of XPath (5.1, 5.2) appear in conflict"

Description:

The WS-SX Charter states on lines 212-222 (red-lined version
from WS-SX F2F): 

    "This work will specifically define
the following: 212 

        1. Mechanism for
specifying what parts of the message must

        be secured, called protection
assertions 214 

        a. Such protection
assertions must be able
to specify

        integrity requirements at both the
element and

        header/body level in a security
policy binding

        (defined below) neutral manner. 217

        b. Such protection
assertions must be able
to specify

        confidentiality requirements at both
the element and

        header/body level in a security
policy binding

        (defined below) neutral manner. 220

        c. Such mechanisms must not require the use of XPath [21]

        but may provide it as an
option." 

I think this clearly states that a mechanism will be defined
that is

able to specify integrity and confidentiality requirements at
an

element level without using XPath. 

However, section 5.1 of WS-SecurityPolicy states:

    " 5.1 Integrity Assertions

        Two mechanisms are
defined for specifying the set of

        message parts to integrity protect.

        One uses QNames to
specify either message headers or

        the message body while the other
uses XPath expressions

        to identify any part of the
message." 

A similar introduction exists in section 5.2 and in both
sections the

followup text elaborates consistent with introductions.

My interpretation is that this is inconsistent with part c of
the quoted

text from the charter above, because neither mechanism allows
the

the addressing at the element level without XPath (the first
does not

allow element addressing at all, the second uses XPath).

Finally, what raised my concern in the first place was that I
was looking

for an element-specific non-XPath mechanism, which I thought
would

be described in section 5.1.1.  I read the text several
times, but only

at the meeting when it was stated that SignedParts only
applied to

the Body as a whole did I realize that the text then was
consistent. 

However, if only the Body can be addressed this does not meet
the

requirement of part a. in the quote from the charter above.

Related
issues: 

The original issue at the meeting was captured in the F2F
minutes by Michael as: 

">Rich: question about SignedParts: Section 5.1.1
text is misleading about

how fine grained it is" 

Proposed
Resolution: 

Assuming my interpretation is correct, my suggestion is to
either: 

        1. loosen the restriction
in part c to say a mechanism such as

        XPath may be required

        or 

        2. add a 3rd mechanism to
sections 5.1, 5.2 

My concern also is that I am not aware of any 3rd mechanism.

Possibly wsu:Id or xml:id could be inserted to a target
element,

but that might cause xml validation issues. 

Thanks, 

Rich