Re: [xacml] Revised proposal for issue #11, using XPath/URI pathexpressions

[Erik Rissanen <erik@axiomatics.com>]

Hi Rich,

No, I still don't understand how the identifiers could be used as xpaths 
in policies.

I can understand the regexp case. For instance, assume that the request 
contains

<Attributes Category="resource">
  <Attribute AttributeId="resource-id">
    <AttributeValue 
Datatype="anyURI">http://example.com/foo#*:bar[namespace-uri='example.com/ns1']</AttributeValue>
...
  </Attribute>
...
</Attributes>

then one could do something like this in a policy:

<Match MatchId="urn:....:anyURI-regexp-match">
  <AttributeValue Datatype="string">...some regexp here...</AttributeValue>
  <AttributeDesignator AttributeId="resource-id" Datatype="anyURI"/>
</Match>

But how would you use the resource-id as an xpath expression? Where 
would you put it in the policy and using what construct?

Best regards,
Erik

Rich.Levinson wrote:
> Hi Erik,
>
> You were right about the syntax, there needs to be a leading "*" in 
> order to collect "all" the child nodes and then discriminate based on 
> local-name() and namespace-uri(). However, I did find the 
> "*:<local-name-literal> works as well, so I modified the spec 
> (attached) to include a leading "*:" (star-colon) before the 
> local-name-literals. I also added a couple of notes to indicate that, 
> as well as pointing out that the strings
>
>    * /*:abc[namespace-uri()=""]
>    * /abc
>
> are equivalent, so that for the no-namespace use cases, there is no 
> need for the prefix and predicate.
>
> On the issue of how xacml treats the identifier, I finessed that a bit 
> as follows: it is the <fragment> item that is serving as the 
> identifier within the XML document itself. So, as specified, it should 
> work as an xpathExpression, possibly without the leading "/", in an 
> AttributeSelector. The proposed specification says that the 
> expressions that conform to the proposed <fragment> layout only need 
> to be percent-encoded when put within a URI. So, for example, if one 
> wanted to use it as the AttributeValue for a resource-id Attribute, 
> there is no technical reason why it needs to be percent-encoded.
>
> Regarding issue 11, the problem was to pin down a consistent syntax so 
> that regular expression matching rules could be specified. The 
> original proposal I submitted addressed this issue by providing a 
> non-xpath syntax in the hierarchical URI scheme, which provided an 
> "alternative" representation for identifying the nodes in an XML 
> document.
>
> Further analysis of the problem, and especially Paul's raising the 
> issue of resource-id's caused me to consider the present proposal, 
> which I consider superior to the original proposal because it serves 
> to layout a method by which identifiers can be automatically produced 
> that can be used by both the XPath representation and the URI 
> representation, which potentially provides a clean break between the 
> naming of the node and the accessing of the node. The particular XPath 
> syntax proposed appears to enable the separation of these two 
> operations so that the literal XPath expressions can be used either as 
> literal identifiers or operational language statements, that 
> "identify" the node in the former case and "access" the node in the 
> latter case..
>
> Hopefully, the above comments address the concerns you raised.
>
>    Thanks,
>    Rich
>
>
>
> Erik Rissanen wrote:
>> Rich,
>>
>> You say that the identifier serves as"an executable expression that 
>> can be applied to an XML document". That is true from a threoretical 
>> point of view, but there are currently no XACML functions which can 
>> operate on an URI like this. The URI needs to be resolved and then 
>> the path needs to be extracted before it can be applied as an XPath 
>> expressions. So it is a fundamentally new scheme, not a modification 
>> to the XPath scheme which started issue #11.
>>
>> BTW, did you check the XPath syntax? If I recall correctly from the 
>> past, foo[namespace-uri="bar"] does not work. I think I had to do 
>> *[localname='foo'][namespace-uri='bar']. I could be wrong though...
>>
>> Best regards,
>> Erik
>>
>> Rich.Levinson wrote:
>>> To TC:
>>>
>>> As described in previous email:
>>>     http://lists.oasis-open.org/archives/xacml/200911/msg00042.html
>>> I have revised the original proposal submitted for issue 11.
>>>
>>> This proposal is intended to address the same problems as the 
>>> previous proposal, and it also provides a format which can 
>>> potentially be used to address the resource-id naming issue raised 
>>> by Paul Tyson:
>>>     http://lists.oasis-open.org/archives/xacml/200911/msg00032.html
>>>
>>> A summary of expected benefits from this proposal includes the 
>>> following:
>>>
>>>     * The proposal provides an automatic naming method for any node in
>>>       an XML document, in the form of an XPath path expression, that
>>>       may also be used to retrieve the actual node identified.
>>>     * The proposal shows how to map this expression into standard URI
>>>       format by percent encoding each XPath step component that
>>>       follows a URI fragment slash "/".
>>>     * An XPath step in the proposal is represented by the
>>>       concatenation of 3 strings as a local-name plus two optional
>>>       predicates, each of which is immediately determinable when in
>>>       the XPath context of the document using standard XPath
>>>       functions: local-name(), namespace-uri(), and position() and the
>>>       full set of steps in the expression can be used to obtain the
>>>       single node addressed from any XPath context because the path is
>>>       absolute.
>>>     * The unencoded XPath path expression can be used as the identity
>>>       of a node in an XML document as described in section 2.1 of the
>>>       hierarchical profile.
>>>     * The unencoded XPath expression can be used as the resource-id as
>>>       described in section 2.2.3 of the Multiple Resource Profile.
>>>     * The XPath path expression can be used with or without the
>>>       associated XML document. i.e. the expression serves as BOTH an
>>>       executable expression that can be applied to an XML document AND
>>>       a literal identifier that can be used by regular expression
>>>       matching type operations.
>>>     * Percent-encoding of the XPath path expression is only required
>>>       when the expression is used as an actual URI, such as when
>>>       extending the URI mechanism into XML documents to identify
>>>       entities within the document, or when used as an identifier that
>>>       requires URI syntax such as an XML AttributeId attribute.
>>>     * In general, because the XPath path expression can operate as a
>>>       literal identifier, it enables policies to be written against
>>>       resources within XML documents which enable policy evaluation
>>>       before the document is accessed.
>>>
>>> I will try to prepare a slide presentation prior to the F2F. In the 
>>> meantime, hopefully, the information is intended to be 
>>> self-explanatory.
>>>
>>> Comments and suggestions welcome.
>>>
>>>     Thanks,
>>>     Rich
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>
>