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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-dev message

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


Subject: Re: [xacml-dev] xpath, urn:oasis:names:tc:xacml:1.0:resource:xpath


Hi Niko,

I have submitted part of your issue to the TC (that resource:xpath is 
missing from 2.0 spec).

The 2nd part of your issue is regarding the context node and how it is 
used in the examples.
I have reviewed this somewhat and would like to zero in on what the 
exact changes to the
spec might be needed.

First, let's assume the context node is xacml-context:Request as stated 
in sec A.3.15 lines
4907-4908. i.e. "//xacml-context:Request"  - do you agree? (If not, 
please specify.)

Now, looking at the specific ResourceMatch fragment you cite below from 
section 4.2.4.1
Rule 1 lines 1166[a241]-1174[a247], my interpretation is that argument 1 
is "/md:record",
which would translate to "//xacml-context:Request/md:record". Agree?

If so, then I agree that this would return an empty node-set, since what 
we want is:
"//xacml-context:Request/xacml-context:Resource/xacml-context:ResourceContent/md:record"
Agree?

If so, then if we were to change "/md:record" to "//md:record" then I 
think this would
return what I suggested we want just above for arg 1. Agree?

Now for arg 2, my assumption is that the resource:xpath, which we can 
probably
assume is either the default context node "//xacml-context:Request" or
"//xacml-context:Request/xacml-context:Resource/xacml-context:ResourceContent",
either one of which is ancestor to //md:record, and thus would result in 
successful
match. Agree?

If we agree to here, then I think 2 things would be needed to correct 
this situation
in the spec:

 1. we would need to change "/md:record" to "//md:record"

 2. we would need to specify what the identifier resource:xpath really 
means:
    i.e. does it mean the "//xacml-context:Request" node, or the
    
"//xacml-context:Request/xacml-context:Resource/xacml-context:ResourceContent"
    node. Agree?

If so, then I suggest that we take it to mean the latter, which I think 
is the intent of
section B.6 lines 5041-5046, which I believe is an identifier for a 
namespace, which should
match the namespace of the child of the ResourceContent node. (ex. lines 
1157[a233]-
1165[a240])

In fact, if we did that, i.e. specify that "resource:xpath" effectively 
sets the
ResourceContextPath to 
"//xacml-context:Request/xacml-context:Resource/xacml-context:ResourceContent",
then I think "/md:record" would be correct and we would not have to do 
#1 above
to make the example correct. Agree?

Well, that's a lot of things to "Agree?" to, but hopefully it provides a 
context
for addressing this issue.

    Thanks,
    Rich





Niko Matsakis wrote:
> Hello,
>
> I have some questions about the proper behavior of the various xpath 
> functions, and the urn:oasis:names:tc:xacml:1.0:resource:xpath 
> Resource attribute in particular.
>
> It seems to be used throughout the examples in the XACML 2.0 Core 
> specification, but I don't find any text defining its proper values.  
> The XACML 1.0 specification, on the other hand, includes the 
> following: "This identifier indicates that the resource is specified 
> by an XPath expression."  However, I am not sure what that means.  In 
> fact, in XACML 1.0 the Attribute's value seems to be explicitly 
> specified in the request context, but not in the XACML 2.0 spec, where 
> it does not appear.
>
> In general, I am a bit confused about how xpath matching is supposed 
> to work.  The first example rule instance from the XACML 2.0 
> specification, for example, tests that the node(s) matching 
> urn:oasis:names:tc:xacml:1.0:resource:xpath are a subset of 
> /md:record, but it's unclear to me in what context these xpath 
> expressions are evaluated.
>
> It seems the /md:record is not intended to be evaluated in the request 
> context, as that would yield an empty set.  That means it is either 
> evaluate with respect to the "ResourceContent", or perhaps to an 
> external document?  On the other hand, Appendix A.3.15 says that "the 
> XPath epxressions in these functions are restrict to the XACML request 
> context.  The <xacml-context:Request> element is the context node for 
> every XPath expresion," which would seem to mean that /md:record 
> should yield an empty set after all (as the request context's root 
> element is a <xacml-context:Request> element).
>
> Can anyone help clarify things for me, or point me to an explanation? 
> Thank you very much!
>
> For reference, here is the XACML policy fragment that invokes 
> xpath-match:
>
>> <ResourceMatch 
>> MatchId="urn:oasis:names:tc:xacml:1.0:function:xpath-match">
>>        <AttributeValue 
>> DataType="http://www.w3.org/2001/XMLSchema#string";>
>>         /md:record
>>        </AttributeValue>
>>        <ResourceAttributeDesignator
>>         AttributeId="urn:oasis:names:tc:xacml:1.0:resource:xpath"
>>         DataType="http://www.w3.org/2001/XMLSchema#string"/>
>> </ResourceMatch>
>
> The example request context is in section 4.2.2.
>
>
> Thanks in advance,
> Niko Matsakis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-dev-help@lists.oasis-open.org
>


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