Hi Paul,
That's an interesting suggestion about XPointer. I had looked at it
earlier and become somewhat discouraged because of both my personal
experience with it in the context of XML Signature and the fact that
the specs never seemed to me to have a clear focus, and appear to be
left in a somewhat unfinished state (for example:
http://www.w3.org/TR/xptr-xpointer/).
That being said, it is probably worth revisiting in the current
discussion. XPointer did appear in XACML 2.0 example: lines 1063-1065:
1063 [a184] //med.example.com/records/bart-simpson.xml#
1064 [a185] xmlns(md=:Resource/ResourceContent/xpointer
1065 [a186] (/md:record/md:patient/md:patientDoB)
which we decided to remove, because it appears syntactically incorrect
and we weren't sure exactly what it was trying to say.
However, (considering http://www.w3.org/TR/xptr-xmlns/) it does seem to
me that the following syntax might be correct:
//med.example.com/records/bart-simpson.xml#
xmlns(md=:"urn:example:med:schemas:record")
xpointer(Resource/ResourceContent/md:record/md:patient/md:patientDoB)
However, I think the syntax we have developed in the emails over the
last couple of days can also be used here, with the advantage that it
makes the "prefix problem" go away, in which case, the above example
could be alternatively represented as:
//med.example.com/records/bart-simpson.xml#
xpointer(Resource/ResourceContent
/*:record[namespace-uri()="urn:example:med:schemas:record"]
/*:patient[namespace-uri()="urn:example:med:schemas:record"]
/*:patientDoB[namespace-uri()="urn:example:med:schemas:record"])
The above syntax removes the random "md", which is a problem for
regular expression matching, because what is needed is the value the
prefix represents, which is a well defined string, as opposed to the
prefix which can be a randomly set string which cannot be relied upon
for regexp matching. (Note: I am not sure if the
Resource/ResourceContent is actually required, but if it is, then each
of those elements will require a namespace-uri() predicate as well,
because they use the default namespace as opposed to no namespace.)
Assuming that the above is correct, I am attaching a slightly modified
proposal to incorporate your suggestion, which defines the fragment as
follows:
<fragment> = "xpointer(/" <fragment-id> ")"
which should allow the <fragment-id> to be a relative XPath path
expression that can be used wrt to the Context element for
data-type:xpathExpression and/or the ResourceContextPath attribute.
Also, in the intended usage, the "xpointer()" function itself will
never need to be actually executed, as its purpose is to only conform
to the XPointer framework syntax.
Thanks,
Rich
Tyson, Paul H wrote:
3898C40CCD069D4F91FCD69C9EFBF096040BFE5E@txamashur004.ent.textron.com"
type="cite">
Rich,
Did you consider whether the XPointer framework
would work for the fragment part of the URI?
It provides for namespace binding, and a few
different schemes for locating elements within an xml resource.
--Paul
-------- Original Message --------
Subject: Re: [xacml] Revised proposal for issue #11, using XPath/URI path expressions
Date: Wed, 25 Nov 2009 13:37:34 +0100
From: Erik Rissanen <erik@axiomatics.com>
To: Rich.Levinson <rich.levinson@oracle.com>
CC: xacml <xacml@lists.oasis-open.org>
References: 4B09DAA8.8010601@oracle.com"><4B09DAA8.8010601@oracle.com> 4B0A87B4.6000103@axiomatics.com"><4B0A87B4.6000103@axiomatics.com> 4B0B289E.3080907@oracle.com"><4B0B289E.3080907@oracle.com> 4B0B9B24.8030804@axiomatics.com"><4B0B9B24.8030804@axiomatics.com> 4B0CE0CD.60303@oracle.com"><4B0CE0CD.60303@oracle.com>
Hi Rich,
Thanks for the clarification. I thought you said that the same attribute
values (and thus the same request) could be used directly for both
schemes without modification.
But what you actually say is that the same fragment can be reused as a
piece to implement either scheme, though separately. I would agree with
that.
Best regards,
Erik
3898C40CCD069D4F91FCD69C9EFBF096040BFE5E@txamashur004.ent.textron.com"
type="cite">
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:
4B0B9B24.8030804@axiomatics.com" type="cite">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
|