Rich,
Did you consider whether the XPointer framework would work
for the fragment part of the URI?
http://www.w3.org/TR/2003/REC-xptr-framework-20030325/
It provides for namespace binding, and a few different
schemes for locating elements within an xml resource.
--Paul
From: Rich.Levinson
[mailto:]
Sent: Wednesday, November 25,
2009 01:46
To: Erik Rissanen
Cc: xacml
Subject:
Re: [xacml] Revised proposal for issue #11, using XPath/URI path
expressions
Hi Erik,
Let me try to explain with a very simple example
just to show the flow.
Say we have an xml document foo.xml w
content:
<A><B>BValue</B></A>
located at
<uri> = http://ex.com/foo.xml.
For simplicity, assume the caller knows nothing of the files or xml, but
that the pep somehow knows the user needs to access the content of /A/B in
order to be granted access.
Also to simplify discussion, assume there is another clause in the
proposal that says:
<fragment> = "/" <fragment-id>
so the
discussion following without losing generality will focus on
<fragment-id>, which consists of everything on line 254 of proposal
except for the leading slash.
According to the proposal, the <fragment-id> that would be created
to access /A/B, would be:
<fragment-id> =
*:A[namespace-uri()=""][1]/*:B[namespace-uri()=""][1]
which, because of
the empty namespace-uri value, would reduce to:
<fragment-id> =
A[1]/B[1]
Now, using core Example 2: request context section 4.2.2 and rule 2,
section 4.2.4.2 as a guide, for the request context, we could include an
Attribute as follows:
<Attribute
AttributeId="...resource:resource-id">
<AttributeValue
XPathCategory="...attribute-category:resource"
DataType="...data-type:xpathExpresssion"
>A[1]/B[1]</AttributeValue></Attribute>
where we just
insert <fragment-id> as the AttributeValue.
Similarly, the policy, like 4.2.4.2 lines g64-g75 would
say:
<Match MatchId="...function:xpath-node-match">
<AttributeValue
DataType="...data-type:xpathExpression"
XPathCategory="...attribute-category:resource"
>A</AttributeValue>
<AttributeDesignator
MustBePresent="false"
Category="...attribute-category:resource"
AttributeId="...resource:resource-id"
DataType="...data-type:xpathExpression">
</Match>
By comparison, with the URI method, one would submit a resource-id
of:
<uri>#/<fragment-id>
and use regular expression
matching as we've discussed.
The point is that the same
automatically constructed string, <fragment-id> could be used by both
methods. And, the reason I am suggesting it, is that for the multiple resource
profile, for both the xml and non-xml use cases there is a need for
constructing resource-id's, which are capable of individually addressing every
node in an XML document. It seems to me that this technique, which I believe
enables the URI approach to encompass both non-XML and XML resources, can be
used with the XPath-oriented method as well.
Thanks,
Rich
Erik Rissanen wrote:
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
