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.
Let me try to explain with a very simple example
just to show the flow.
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.
- Say we have an xml document foo.xml w
<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>
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:
which, because of
the empty namespace-uri value, would reduce to:
- Now, using core Example 2: request context section 4.2.2 and rule 2,
section 220.127.116.11 as a guide, for the request context, we could include an
Attribute as follows:
where we just
insert <fragment-id> as the AttributeValue.
- Similarly, the policy, like 18.104.22.168 lines g64-g75 would
- By comparison, with the URI method, one would submit a resource-id
and use regular expression
matching as we've discussed.
Erik Rissanen wrote:
4B0B9B24.firstname.lastname@example.org 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
then one could do something like this in a policy:
Datatype="string">...some regexp here...</AttributeValue>
But how would you use the
resource-id as an xpath expression? Where would you put it in the policy and
using what construct?
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
so that for the no-namespace use cases, there is no need for the prefix
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.
Erik Rissanen wrote:
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...
As described in previous email:
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:
A summary of expected benefits from this proposal includes the
* The proposal provides an
automatic naming method for any node in
an XML document, in the form of an
XPath path expression, that
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
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
local-name(), namespace-uri(), and position() and the
full set of steps in the expression
can be used to obtain the
node addressed from any XPath context because the path is
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
* 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
* Percent-encoding of the
XPath path expression is only required
when the expression is used as an
actual URI, such as when
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
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.
To unsubscribe from this mail list, you must leave the OASIS TC
generates this mail. Follow this link to all your TCs
in OASIS at: