Proposal to address issue 11, and thoughts on whether it is advisableor not to separate out sections of hier, mult to a new profile

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.

  
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.

      

    

  
  
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.

      

    

  
  
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

xacml-3.0-hierarchical-v1-spec-cd-1-en-rich-uri-xml-prop-1a.doc