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:Richard.Levinson@ca.com]
Sent: Tuesday, December 13, 2005
1:08 PM
To: ws-sx@lists.oasis-open.org
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