Proposed Revision to Hierarchical Profile

["Hal Lockhart" <hal.lockhart@oracle.com>]

On the last call I outlined what I believe is the current consensus proposal for changes to the hierarchical profile.

It is agreed we need some cleanup on definitions and the section on URI formats.

There will be three modes of operation, each with its own identifier. The first, XML document would remain as it is today.

A second one, based on hierarchical URIs could be used only by singly rooted hierarchies (although there could be as many as desired). The hierarchy would be reflected in the naming structure. The Resource would have one or more names which were hierarchical URIs. No Ancestor or Parent attributes would be provided. The policy would assume that the parents and ancestors can be determined by parsing the URIs. For example, a resource named:

file://example.com/x/y/z/r would have a parent of file://example.com/x/y/z and ancestors of file://example.com/x/y/ and file://example.com/x

Note that the same resource could also have other names which might include the same or differently named parents and ancestors. 

We would define a hierarchical URI as any scheme with hierarchical name structure where levels are separated by slashes. (http: & file: are hierarchical, email: and urn: are not). Resources already using a hierarchical URI for naming could present that in the Request Context. If the resource name has some other form, a hierarchical URI would be constructed using the file: scheme.

The third scheme would use the parent and ancestor attributes. Attributes could be named in any way. It would not be required that resources and ancestors use the same naming structure or datatype for names. Any resource, parent or ancestor could have the same name in all hierarchies or different names in different hierarchies. No information about the hierarchy could be obtained from the name structure. 

The steps for this would be first to collect all hierarchies of which the resource is a member. Then all descendants of the resource are discarded. Then all parents and ancestors in each hierarchy are enumerated, discarding duplicates.

Note that the initial hierarchies can be singly or multiply rooted. If you wish to think of them being represented as a DAG that is fine, however the union of the hierarchies is by no means guaranteed to be a DAG as it may contain cycles. This causes no problems, because descendants are discarded, so the only possible inconsistency can be between separate requests. XACML has never required any kind of consistency of inputs between distinct requests.

On the call Thursday there were no objections to this proposal, however Erik and Daniel were not present. I would like to hear right away from you guys if there is some part of this you can not live with.

We did not discuss conformance, but I suspect we will need to have three conformance clauses, corresponding to the three modes.

Hal