Issue #87 CORE ERRATA: resource:xpath needs to be added in B.6, plusfix needed for 4.2.2 example - updated

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.

    Thanks,
    Rich


      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 </xacml/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 
</xacml/RequestContextPath> for the parent attribute is 
"//xacml-context:Request/xacml-context:Resource/xacml-context:ResourceContent 
</xacml/ResourceContent>".

    * urn:oasi:names:tc:xacml:1.0:resource:xpath"

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 </xacml/ResourceContextPath> to the 
<ResourceContent </xacml/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:

    *

      <Resources>

          o

            <Resource>

                +

                  <ResourceMatch </xacml/ResourceMatch> MatchId
                  </xacml/MatchId>="urn:oasis:names:tc:xacml:1.0:function:string-equal">


                      #

                        <AttributeValue </xacml/AttributeValue> DataType
                        </xacml/DataType>="http://www.w3.org/2001/XMLSchema#string">
                        <http://www.w3.org/2001/XMLSchema#string%22%3E>

                            *

                              http://www.med.example.com/schemas/record.xsd

                        </AttributeValue
                        </xacml/IssuesList/AttributeValue>>
                        <ResourceAttributeDesignator
                        </xacml/ResourceAttributeDesignator>

                            *

                              AttributeId
                              </xacml/AttributeId>="urn:oasis:names:tc:xacml:2.0:resource:target-namespace"
                              DataType
                              </xacml/DataType>="http://www.w3.org/2001/XMLSchema#string"/>
                              <http://www.w3.org/2001/XMLSchema#string%22/%3E>


                  </ResourceMatch </xacml/IssuesList/ResourceMatch>>
                  <ResourceMatch </xacml/ResourceMatch> MatchId
                  </xacml/MatchId>="urn:oasis:names:tc:xacml:1.0:function:xpath-node-match">


                      #

                        <AttributeValue </xacml/AttributeValue> DataType
                        </xacml/DataType>="http://www.w3.org/2001/XMLSchema#string">
                        <http://www.w3.org/2001/XMLSchema#string%22%3E>

                            * /md:record

                        </AttributeValue
                        </xacml/IssuesList/AttributeValue>>
                        <ResourceAttributeDesignator
                        </xacml/ResourceAttributeDesignator>

                            *

                              AttributeId
                              </xacml/AttributeId>="urn:oasis:names:tc:xacml:1.0:resource:xpath"
                              DataType
                              </xacml/DataType>="http://www.w3.org/2001/XMLSchema#string"/>
                              <http://www.w3.org/2001/XMLSchema#string%22/%3E>


                  </ResourceMatch </xacml/IssuesList/ResourceMatch>>

            </Resource>

      </Resources>

Note: that the 2nd ResourceMatch </xacml/ResourceMatch> is a somewhat 
"odd" construct in that it uses an AttributeDesignator 
</xacml/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 </xacml/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 </xacml/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 </xacml/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:

    *

      "xmlns:(md=:Resource/ResourceContent
      </xacml/ResourceContent>/xpointer"

should be changed to read:

    *

      "xmlns:(md=http:www.med.example.com/schemas/record.xsd) xpointer"

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 3.3.1.1 "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*