[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]