Hi Erik,
What I am proposing is not a new "matching language". What I am
proposing is a definitive URI fragment syntax to specify the
hierarchical path to an XML node in an XML document. There are two
steps required, starting from the existing xml format, which is a
sequence of constructs of the following format:
< nsprefix : localname xmlns:nsprefix = "resolved-ns"
>
The above format is not compatible w URI for the simple reason that URI
has no provision for supporting multiple components, of which xmlns is
a component separate and distinct from "nsprefix:localname".
Therefore, to come up with a single component unambiguous definitive
identity for a node, one must simply resolve the prefix and transform
the above format to a sequence of constructs of the following format:
/ resolved-ns : localname
The above format is unambiguous, however the character format of the
resolved-ns and the following ":" are not compatible w maintaining the
URI structure and so must be isolated, which is the point of the "Clark
notation" which simply removes the ":" and puts curly braces around the
resolved-ns, so that we now have a sequence of constructs of the
following format:
/ { resolved-ns } localname
This 2nd step also requires percent encoding any characters, which
include the "{", "}" and any chars in the resolved-ns not permitted in
URI names.
In addition, provision is made using the same xpath techniques for
identifying multiple child nodes w same {resolved-ns}localname with
square brackets, "[", "]", and using "@" for attributes, all of which
must also be percent-encoded.
The result is a definitive URI hierarchical fragment path uniquely
identifying each element node and attribute node in the xml document.
That is the end of the specification.
Any "matching rule semantics" using regular expressions are totally up
to the policy definitions. The exact same techniques would be used as
used for first parts of the URI described in section 2.2 of the
hierarchical profile. The proposal is a simple appending of section
2.2.1 to enable defining the full logical path to resources whether
they be fully identified using only the first parts of the URI or also
using the fragment part, which is designed explicitly to selectively
identify specific entities within a file. The technique works because
the whole hierarchical path is contained within the URI, and therefore
has deterministic hierarchical features which do not need additional
semantics to represent.
This proposal is based on a fully determinate transformation, which
simply resolves the namespace prefixes of the XPath Data Model, as well
as providing the XPath constructs for xml attributes and equally named
peer nodes, and then applies the URI syntax requirement of
percent-encoding the necessary characters.
It is not a new language, it is a representation of the hierarchical
form of the XPath Data Model. It is not intended to address any aspect
of XPath beyond using XPath's hierarchical full paths.
Therefore it is not a new language, but simply a representation of the
definitive node-naming scheme contained in the XPath Data Model.
I believe it really is totally analogous (in a mathematical sense) to a
URL representation of a path to a file in a Windows operating system.
i.e. basically the Windows OS file name is transformed from the C:\
...\filename representation to a /.../filename URL representation. In
the XML doc case the proposal is a transform from the xpath data model
namespace-prefixed representation to a URI namespace-resolved
representation.
Hopefully, this email will have clarified further the scope and intent
of the proposal, and also helps explain that the intent is to fill a
significant gap in coverage of hierarchical resources by the URI
mechanism, which is a gap resulting from not applying the implicit
hierarchical coverage that a URI entails to the XML representation of a
hierarchy. i.e. this is just applying a mapping between two
hierarchical representations of the same core information (the set of
namespace-prefixed QNames of the element and attr nodes).
Thanks,
Rich
Erik Rissanen wrote:
Hi
Rich,
There is one more concern which I have about this new matching
language. Once the language is there, it is going to be subject to
feature creep. In the long term it is going to be a reinvention of
XPath.
Best regards,
Erik
Erik Rissanen wrote:
Hi
Rich,
Yes, I think I understand what you are aiming for. What I meant is that
the working draft which you posted does not contain any text about how
these forms of URIs map in to XML nodes. Without that, it's just lots
of URIs floating in the air, and not a real alternative to XPath for
XML resources. The syntax is there, but not the semantics.
Here is the syntax and semantics of XPath 2:
http://www.w3.org/TR/xpath20/
That explains what are valid expressions and what the expressions mean.
If the XACML TC is going to define our own XML matching language, then
we need to provide some similar text to explain how it works. Not just
its syntax.
Best regards,
Erik
Rich.Levinson wrote:
Hi Erik,
I can either reply with a long detailed email or try something short
and hopefully to the point. I will try the short approach.
First, I think we can all agree, for example, that a list of files in a
file system can represented equally well by a "dir listing" or a "dir
listing that has been channeled into an xml document format", such that
if one is handed the xml document then they can easily use the document
to tell them how to navigate to any file in the file system of interest
to them. i.e. there is an interchangability between actual file system
navigation and navigation thru an xml document.
Given that relatively simple point, without going into detail of all
the syntax, brackets, and curly braces vs namespace prefix discussion,
I think the objective I am trying to achieve w the proposal can be
simply stated, namely:
The objective of the proposal is to provide the ability to system
admins to use the same web access URI techniques they currently
use to control access to html files, for example, and apply those
techniques to control access to nodes in xml documents.
i.e. the proposal is not intended to enable an admin to say any more
about accessing a node in an xml document than the admin would be able
say about accessing an html file that was addressable w the exact same
path.
i.e. the first part of the URI, the existing Hier section 2.2,
would be used to identify the specific xml file,
then the second part, the fragment identifier would be able to use
the same slash-component technique to identify the node within the
XML document.
The admin would write policies that would say something like:
grant admingroup readprivilege
http://www.example.com/section01/*.xml#/a/b/c/-
which would allow the admin group to read nodes below the "/a/b/c/"
level in section01 of www.example.com.
So, if someone came in with an http GET on:
resource-id = http://www.example.com/section01/file01.xml#/a/b/c/d
the policy above would allow access if they were in the admin group.
I realize the above policy is not in xacml, however, one could fairly
easily have the admingroup as the subject target, the readprivilege as
the action target, and then write a regular expression to test the
resource-id against the scoped policy.
Probably no need for constructing resource lists, multi requests could
be simply like:
resource-id = http://www.example.com/section01/file01.xml#/a/b/c/*
which would effectively be a query for all the child nodes of /a/b/c in
the doc file01.xml.
Hopefully, this is enough to make the objectives more clear, and show
why with this relatively limited scope of objective there is no real
need for document content to be provided in the requests, and policies
can be written such that everything can be determined from the query
alone.
The point is that current web access control products effectively
provide these capabilities, and the idea is to simply provide a
technique to extend this type of capability to the nodes of xml
documents.
Thanks,
Rich
Erik Rissanen wrote:
Hi Rich,
One thing which is missing from this proposal is that there is no
specification for how the URI selects nodes in the XML document.
Personally I find it difficult to work with expressions like this since
it is about performing "matching on a matching language" in order to
get the actual resource. I am concerned that it is easy to make a
mistake in this dual step matching process, but if others find it
desirable to work with, I could live with it in the spec. :-)
I understand that it may be desirable in some cases to hide the XML
content, but that could perhaps be handled better by a construct like
this:
<Request>
<Attributes Category="resource">
...
<ContentReference .....something here..../>
</Attributes>
</Request>
With a content reference like this in the core schema, the
<Request> element could be used as a transport format where the
XMl can be hidden. And there would be no need to introduce another
conceptual model for hiding the XML content. When the PDP receives a
<Request> like this, it would conceptually replace the XML
content and behave according to the current spec. (Or based on yet
another hierarchical scheme which we define.)
Best Regards,
Erik
Rich.Levinson wrote:
Based on Oct 8 TC meeting, proposals were
solicited to address both issue 11, and the broader issue of whether or
not we should consider separating out the XML document parts of Hier,
Mult to another profile.
The attached document represents a proposed addition to Hier profile to
address issue 11 (it is the same as attachment to
http://lists.oasis-open.org/archives/xacml/200909/msg00076.html, except
w highlight changes turned off to make Hier sections 2.2, 2.2.1 easier
to read). (It is also included as attachment to emphasize it is a
proposal, as opposed to a draft of an agreed change, which would be
rev'd in the repository)
The following comments state why I think the proposed addition to Hier
is needed (#1, #2) and why I think the hierarchical properties of XML
documents should remain in the Hier/Mult profiles (#3), and that if
other profiles are developed for XML docs then those profiles should
refer to Hier/Mult for their hierarchical access properties.
1. The proposed addition to Hier is needed because it represents
functionality that is currently missing from the Hier profile
that enables identifying resources within an XML document
without having to provide the XML document itself.
* The problem introduced by requiring the presence of the
XML document is that, for example, it requires actually
accessing and exposing the protected resources in order to
determine if access is allowed to those same resources.
While this may be an acceptable increase in risk of
exposure in some application environments, it may not be
acceptable in others where very sensitive data is
involved, and an alternative should be provided for those
cases.
* For more specific example, XML-frontended datastores
contain resources in relational or other legacy storage
mechanisms and primarily use XML as vehicle for containing
and carrying those resources. Requiring construction of
XML documents containing those resources, which could
potentially contain very sensitive data, in order to
construct a request to determine whether access to those
resources is allowed should not be required if alternative
mechanisms which do not require this exposure are readily
available.
2. The proposed addition is also needed to provide a unique uniform
naming mechanism and policy reference mechanism for all
hierarchical resources whether they are contained in an XML
document structure or some other hierarchical structure. i.e.
XML documents have an inherently simple hierarchical structure
that has an implicit resolved name structure in the underlying
XPath data model that should be able to be used for resource
identification and policy definition despite the fact that the
XPath language, itself, does not expose this capability of the
underlying reference model.
* The attached proposal uses a commonly used mechanism
(Clark notation: curly braces around resolved namespace
prefix) that addresses the omission from the XPath
language of the ability to enable single string display
representation of explicit full hierarchical path to each
node. This path is also percent-encoded where required in
order that it can be used as a URI fragment as described
in section 2.2.1 of attachment, which seamlessly augments
the existing Hier URI scheme in section 2.2.
3. It is recommended to leave the XML document sections in
Hier/Mult for the following basic reason: The introduction to
the Hier profile (section 1, lines 41-54) makes it clear that
XML documents are regarded as generally only one possible
"representation" of the actual target hierarchical resources.
Therefore there seems to be little to be gained by separating
out one representation of the general hierarchical resources
covered by the profile into a separate profile. What would seem
to make more sense is that a more general XML/WebServices
profile could reference the Hier profile when necessary for
matters concerning the "hierarchical" access control aspects of
the more general XML/WebServices problem space addressed by
that new profile.
Additional context for this proposal has already been discussed in tc
emails and will not be repeated here, but may be found in the following
references to those emails:
* The change represents missing functionality as initially
outlined here:
http://lists.oasis-open.org/archives/xacml/200909/msg00075.html
* The specific change that was outlined in above ref, was
explicitly contained in the attachment to this email:
http://lists.oasis-open.org/archives/xacml/200909/msg00076.html
* Trade-offs between the URI and XPath approach, including the
fact that URI does not require the presence of the actual XML
document, were considered in this email:
http://lists.oasis-open.org/archives/xacml/200909/msg00079.html
* A detailed walkthru of one possible use case, selected to show
direct comparison between the XPath and URI approaches was
contained in this email:
http://lists.oasis-open.org/archives/xacml/200909/msg00099.html
* The following email discusses in more detail the relation of the
URI-reference scheme naming and the implicit Mult scoping:
http://lists.oasis-open.org/archives/xacml/200910/msg00007.html
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
