Re: [xacml] Working toward solution to Hierarchical profile Issue

The problem presented by the commenter is analagous to:

    State/City01/MainStreet
    State/City02/MainStreet

Just because two separate cities have a street named MainStreet does not mean these are the same street. These are two distinct normative identifiers for two distinct resources.

Yes, those are too distinct identifiers, and XACML does not need to know anything about its internal structure.    You could identify streets by there geographical coordinates, cities by zip codes and states by the last name of its governor. It will work the same.   No naming schemes are needed in any form or shape.

While it is true that xacml does not "need" to know anything about the internal structure of the identifiers, xacml at the same time "defines" functions such as anyURI-regexp-match and a host of others designed to deal with the internals structure of identifiers and capitalize on the value inherent in those value-added constructs to a basic string.

They are designed to be used against data defined outside of the XACML specification. Key difference here is that XACML does not specify anything about them. Nobody should be forced to invent and maintain a resource categorization scheme just to be able to use normative hierarchical policies.

DAG cannot support this construct, because it retains no information about its connections other than source and destination node. i.e. any hierarchical information in a set of attaching nodes is automatically lost when joining the DAG.

No information other then that is needed for policy evaluation so it is omitted on purpose. Details of the resource ontology supported by the external system are irrelevant to the PDP.

This approach introduces the absolute minimum (none) of new concepts that PDP need to understand. You do not need to maintain and process any naming schemes. It covers all possible structures for the purpose of policy inheritance. It does not need to cover anything else.

Hierarchical naming schemes are really irrelevant for this discussion, because their value is primarily for use with Forests. They have little or no value in the more general DAG, so I can understand why you consider them unnecessary and extraneous. However, for a Forest they can have significant value.

Naming schemes should not be a subject of discussion as XACML does not need to know anything about any naming schemes. They are part of an external system. We may create a profile that make use of a naming scheme - and we have done that for "XML type" hierarchy, but I think it should not be a part of the core XACML.

Proper course would be to split it, and leave one for XML documents/URI and one for "ancestors" approach.

Basically, I do not believe the public, in general, or even the highly technical public can be assumed to understand the distinction between Forest and DAG, at least not without a brief explanation similar to what I tried to do above, so I recommend including such information, possibly in the Glossary of any option.

I have not had any troubles explaining the existing approach to both technical and non technical people so far. This discussion is the first case.

Here are some options in addition to an explanatory glossary, I consider reasonable:

Modify existing document so that nonXML nodes are described with DAG option and with Forest option. This can be done minimally as follows:

Change the identifier in section 2.2 to indicate that it is forest-oriented:

"urn:oasis:names:tc:xacml:2.0:profile:hierarchical:forest:non-xml-node-id"

Making an incompatible identifier change is probably not a good idea.

P.S. On the side note, when we designed a protection scheme for XML data structures for what is now known as Oracle Data Service Integrator, we found it next to useless trying to rely on XML data structure for the purpose of policy inheritance. We chose to bind schema elements directly to protected resources that followed their own separate and more generic hierarchy. That allows a reuse of policies independent of transformation and re-factoring of the XML. That is similar to the issue of maintaining any hierarchical naming schemes for enterprise resources - you do want to decouple them from access policy rules.

Daniel;

Hopefully, some other people will be able to objectively review this information in its consolidated form and provide input. Personally, I can't think of much more to say about it. Also, I think it has been a useful exercise, and I appreciate the time and effort that Daniel has expended to help reach the current level of understanding of the situation. I know I have learned a lot.

xacml message