Re: [xacml] Proposal to address issue 11, and thoughts on whetherit is advisable or not to separate out sections of hier, mult to a new profile

[Erik Rissanen <erik@axiomatics.com>]

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