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