OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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

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:

  <Attributes Category="resource">
    <ContentReference .....something here..../>

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,

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 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]