OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: Re: [xacml] Issue #87 CORE ERRATA: resource:xpath needs to be addedin B.6, plus fix needed for 4.2.2 example - updated

This email to follow up on last TC meeting's action item:

  Issue 87:
      Rich: Need xpath feedback from others - i.e. someone who
      "knows" what the xpath constructs are "supposed to be"

       Rich to provide specific proposal for changes. Options of
       required optional/ resource:xpath in attr designator. (will
       be based on deduction of intent of xpath in spec unless
       specific feedback provided)

Based on the above action item, and that afaik there has not been
anyone who has submitted more info on this issue, I will now
explain as best I can my interpretation of the intent of the current
spec and recommend the change necessary to match that intent.
(This will be followed by some supporting comments listing the
main specifics leading to these conclusions.)

I have reviewed the xacml 1.0, xacml 1.1, and xacml 2.0 specs
to set up a context for understanding what changed. My conclusion
is that resource:xpath was accidentally removed from xacml 2.0 and
that the only way to make sense of its use in the example policies
is to assume that when it is specified in a ResourceAttributeDesignator,
that xpath in the AttributeValue of the ResourceMatch must have as
a context node the ResourceContent element of the Request.

Therefore, my proposal is that the proposal in issue 87 for adding back
the resource:xpath identifier with the following text will substantially
correct the situation:

    ' This identifier indicates that the resource is specified by an XPath
        expression and that the default RequestContextPath for the
        parent attribute is "//xacml-context:Request/

    * urn:oasis:names:tc:xacml:1.0:resource:xpath '

The above is the proposal. Now here are some of the specific things
I found which led me to these conclusions:

  1. In xacml 1.1 section B.6 contains several attribute identifiers including
       resource-id and xpath.
      In xacml 2.0 section B.6 all the above attribute identifiers have been
       removed, except for resource-id, and a new xacml.2.0 identifier
       has been added: target-namespace.
  2. The description in the example Rule 1 of the ResourceMatch containing
       the ResourceAttributeDesignator (lines 1166-1174 and lines 1244-1247
       clearly indicate that the resource:xpath identifier is alive and well and
       required for this Policy to continue to function.
      Given the requirement for the Policy to function, it is clear that the context
       node for the xpath string specified needs to be the ResourceContent node
       and not the Resource node.
  3. Given the description of xacml:2.0:resource:target-namespace
       (lines 5041-5046), it is clear that the place to look for the namespace that
       is being described is the ResourceContent node.
  4. Given that lines 4907-4908 say the Request element is the context node for
       every XPath expression, a means to override this is necessary if we just
       want to deal with the content under the ResourceContent, which appears
       to be generally the case.
  5. The xacml:1.0:resource:target-namespace and xacml:1.0:resource:xpath
       Attributes were removed from xacml 1.1 lines 978-992, and incorporated
       thru other means in the xacml 2.0. In the former case thru the xacml 2.0
       defn in section B.6 for xacml:2.0:resource:target-namespace, and in the
       latter case by what is proposed above as the accidentally left out defm
       of resource:xpath, which appears to synergistically, as defined, work
       together with the target-namespace.

Bottom line: the xpath-node-match function is trying to determine if  the node
/md:record is under the node ResourceContent.

As indicated in the issue description, there are other ways to address this
issue or possibly interpret the original intent. However, I believe the above
proposal is the path of least resistance which is consistent with the spec
as it currently stands with the examples given.


Rich Levinson wrote:
Note: the previous version of this issue accidentally went to xacml-demo-tech.
Note: this issue should be reviewed carefully to make sure we end up with a
consistent picture of how xpath is described in the core spec. It appears that
the changes in section B.6 Resource Attributes from V1.1 to V2.0 were
incomplete. The suggestion in the issue I believe will make the spec self-consistent,
however as the note at the end of part 1 implies, there may have been another
intention, which might be a cleaner way to handle it.


87. CORE ERRATA: resource:xpath needs to be added in B.6, plus fix needed for 4.2.2 example

Part 1: Xacml core V2.0 apparently inadvertently left out resource:xpath in section B.6. (This identifier is used in a number of places in the examples: lines 1172, 1337, 1496, 1658) The following lines (inside the quotes), which are modified from the XACML V1.1 spec (4555-4556) to take into account the ResourceContextPath, should be inserted to the XACML V2.0 spec after line 5046:

"This identifier indicates that the resource is specified by an XPath expression and that the default RequestContextPath for the parent attribute is "//xacml-context:Request/xacml-context:Resource/xacml-context:ResourceContent".

It has been deduced from analysis of section B.6 (lines 5041-5045) description of "resource:target-namespace", plus the fact that the "resource:xpath" identifier apparently was inadvertently left out of XACML 2.0, plus examination of the XPaths in the examples that begin with "/md:record" require that the statement about the about the <xacml-context:Request> element being the context node for every XPath expression (Sec A.3.15 lines 4907-4908) be overridden in order to set the ResourceContextPath to the <ResourceContent> element. See analysis in this email: http://lists.oasis-open.org/archives/xacml-dev/200710/msg00005.html

In addition, to understand this situation please refer to lines 1155-1176 of Rule 1:

Note: that the 2nd ResourceMatch is a somewhat "odd" construct in that it uses an AttributeDesignator to specify an XPath. Be that as it may, it is clear that the intent of the resource:xpath identifier is implicitly make the <ResourceContent> node the xpath context node, which is consistent with intention of the resource:target-namespace identifier as well, which is used in the first ResourceMatch.

Note: an alternative solution might be to not use the resource:xpath identifier at all and simply modify the description of the resource:target-namespace to say that it implies that the ResourceContent element is the xpath context node. However, it might be too late for that, although we could add both and mark the resource:xpath as deprecated.

Part 2: In addition, on line 1064 there is a typo 4.2.2 Example request that should be fixed:

should be changed to read:

Note: it had been decided before to fix this: http://lists.oasis-open.org/archives/xacml/200702/msg00001.html and it has been brought up again independently: http://lists.oasis-open.org/archives/xacml-dev/200710/msg00000.html, http://lists.oasis-open.org/archives/xacml-dev/200710/msg00002.html with a preliminary response: http://lists.oasis-open.org/archives/xacml/200710/msg00009.html

Part 3: Finally, some clarifying text about requirements for whether XPointer needs to be supported should be added in section "Rule Target" lines 657-658 where it is explicitly referenced. It shows up in the example on line 1064. i.e. apparently providing XPath capabilities does not implicitly include XPointer, and we should say something about how to include it if desired. Note: in the example it comes in as part of the request. What behavior would be expected if the PDP did not support it?

Status: OPEN

Champions: Rich

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