OASIS eXtensible Access Control Markup Language (XACML) TC

Back to discussions
Expand all | Collapse all

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

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

    Posted 10-13-2007 01:16 
    



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, 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 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


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

    Posted 11-08-2007 04:11 
    

  
  


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/
    
        xacml-context:Resource/xacml-context:ResourceContent".

    
    * 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.

    
    Thanks,
    
    Rich
    
      

    
Rich Levinson wrote:

    47101BC6.1020208@oracle.com" type="cite">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, 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 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


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

    Posted 11-08-2007 18:02 
    Rich,

Sorry for not having had the time to really get into this issue until 
now. I had a look at this and I get the feeling this has been replaced 
with the ..:data-type:xpath-expression from the hierarchical resources 
profile in XACML 2.0. See section 3.1 in that document. It provides the 
equivalent functionality (and much more).

The use of the string data type in the core 2.0 example might be a typo, 
in which case it all makes sense. (Though, I am not sure that example 
should be in the core doc if the functionality is defined in the profile 
doc.)

Anyone of the old days remember what happened? :-)

Best regards,
Erik

Rich Levinson wrote:
> 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/
>         xacml-context:Resource/xacml-context:ResourceContent".
>
>     * 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.
>
>     Thanks,
>     Rich
>       
>
> 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.
>>
>>     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 , 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 
>> ".
>>
>>     * 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 
>>


Related Content