Hi Seth and Daniel,|
It appears to me that this discussion is starting to take a trajectory
independent of what is currently in the Hierarchical resource profile.
This profile, as specified in the abstract and throughout discusses the
procedures for dealing with resources that are structured as
hierarchies and are represented by one of two types of "nodes in a
If that was the end of the spec, then maybe I would agree with your
opinions on how "generic" you are suggesting the non-XML way should be.
However, when you get past the front cover, you quickly come on section
2.2 which states the following:
- In one type the resources are represented as "nodes in XML
- In the other type, the resources are represented "in some non-XML
In case one thinks that is not specific enough wrt to how it relates to
hierarchy, section 2.2 goes on to state:
- The identity of a node in a hierarchical resource that is not
represented as an XML document instance SHALL be represented as a URI
that conforms to [RFC2396]. Such URIs are of the following form.
<scheme> “:” <authority> “/” <pathname>
Finally, section 4, that describes how to state policies that apply to
nodes says in section 4.1:
- The <pathname> portion of the URI SHALL be of the form
<root name> [ “/” <node name> ]*
The sequence of <root name> and <node name> values SHALL
correspond to the individual hierarchical component names of ancestors
of the represented node along the path from a <root> node to the
and for the specifically non-XML resource case in section 4.3:
- The representations of the identities of these parents,
ancestors, or self will not necessarily indicate the path from the root
of the hierarchy to the respective parent, ancestor, or self unless the
representation recommended in Section 3.2(should say 2.2): Nodes
in a resource that is not an XML document is used.
My whole purpose in pursuing this thread has been to correct what I
perceive as a flaw in the spec which to a large degree is the result of
not showing in section 3.2 how URIs can be used as an alternative to
the specific algorithms bulleted in section 3.2.
- For hierarchical resources that are not represented as XML
document instances, and where the URI representation of nodes specified
in Section 2 of this Profile is used, the following functions
described in the XACML 2.0 Specification [XACML] MAY be used to state
policies that apply to one or more nodes in that resource.
(should be ...2.0:function:anyURI-regexp-match)
With URIs you do not need the algorithms because the URIs representing
the normative identities of the requested node already contain:
Nothing else is needed. Note however, that doing the analysis with URIs
points out what might be considered to be a flaw in the bulleted
algorithms. The bulleted algorithms require obtaining all parents of
the requested node's parent on up the line, regardless of whether those
additional parents are connected to the requested node by an explicit
hierarchical relationship or not.
- "each normative representation of the requested node"
- "each immediate parent of the node specified"
- "each ancestor of the node specified"
i.e. the bulleted scheme implicitly forces the requested node to
collect ancestors that have not been structurally assigned any direct
relationship to the requested node. When hierarchies are used to
represent lines of authority, these additional relationships are not
relevant and obscure the real lines of authority which are generally
what is of interest in enterprise security.
With the URI scheme it would be simple enough to collect these
extraneous ancestors if they were desired for some reason, by simply
using the bulleted algorithms as is, and using URIs found in ancestors
that are not on the requested node's direct path.
However, it is my opinion, that the primary purpose of these
specifications is to inform consumers of these specifications on the
capabilities contained within the spec so that they may then apply
those capabilities to meet their needs.
By only including the bulleted ancestor algorithms in section
3.2, the capabilities of URI, which are clearly specified in the rest
of the spec, and were included in the example document in the XACML
archive (see section 4.2, 4.3 of
we are effectively making the URI capability so obscure in the spec
as to be unusable.
The inclusion of the URI in the spec was an essential part of its
creation, although there was not universal agreement as to whether it
should be included, as described in this email:
The fact is that URI was included and it remains there, and from my
perspective represents an extremely significant ease of use capability.
The purpose of my next round of planned changes is to bring the URI out
of the darkness so that a reader of section 3.2 will be aware of its
availability. This also fills the hole between the URI descriptions in
sections 2.2 and 4.3 as URI relates to nonXML resources.
Again, my proposed changes do not change any functionality, they simply
explain the capabilities that are currently there, which because of the
obscure representation of the existing functionality in the current
spec are nearly impossible to understand.
Seth Proctor wrote:
There are many way to create hierarchical
structures. If we are to publish anything, I think it should be the
most generic one that does not introduce any additional concepts to the
XACML (like naming schemes and such).
I agree with Daniel on this point. One of the strengths of the XACML
core (in my opinion) is that it deals with a policy processing model,
not the specifics of how XACML systems interact with the world around
The idea of generic hierarchies is that a PEP should be able to name a
root, and that should result in a PDP processing multiple requests. How
that mapping happens is up to some entity outside the scope of XACML.
It seems to me like what we're really talking about in this thread is a
profile for specific mechanisms or more detailed examples of actual
implementation possibilities. I think this kind of clarity is great to
have, but should be in a separate place from the abstract discussion of
hierarchies (which I think is also Daniel's point). I also think Erik's
suggestion makes sense: we should continue to look at these details,
but move the core docs forward separately.
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: