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,

Yes, I think I understand what you are aiming for. What I meant is that 
the working draft which you posted does not contain any text about how 
these forms of URIs map in to XML nodes. Without that, it's just lots of 
URIs floating in the air, and not a real alternative to XPath for XML 
resources. The syntax is there, but not the semantics.

Here is the syntax and semantics of XPath 2:

http://www.w3.org/TR/xpath20/

That explains what are valid expressions and what the expressions mean. 
If the XACML TC is going to define our own XML matching language, then 
we need to provide some similar text to explain how it works. Not just 
its syntax.

Best regards,
Erik



Rich.Levinson wrote:
> Hi Erik,
>
> I can either reply with a long detailed email or try something short 
> and hopefully to the point. I will try the short approach.
>
> First, I think we can all agree, for example, that a list of files in 
> a file system can represented equally well by a "dir listing" or a 
> "dir listing that has been channeled into an xml document format", 
> such that if one is handed the xml document then they can easily use 
> the document to tell them how to navigate to any file in the file 
> system of interest to them. i.e. there is an interchangability between 
> actual file system navigation and navigation thru an xml document.
>
> Given that relatively simple point, without going into detail of all 
> the syntax, brackets, and curly braces vs namespace prefix discussion, 
> I think the objective I am trying to achieve w the proposal can be 
> simply stated, namely:
>
>     The objective of the proposal is to provide the ability to system
>     admins to use the same web access URI techniques they currently
>     use to control access to html files, for example, and apply those
>     techniques to control access to nodes in xml documents.
>
> i.e. the proposal is not intended to enable an admin to say any more 
> about accessing a node in an xml document than the admin would be able 
> say about accessing an html file that was addressable w the exact same 
> path.
>
>     i.e. the first part of the URI, the existing Hier section 2.2,
>     would be used to identify the specific xml file,
>     then the second part, the fragment identifier would be able to use
>     the same slash-component technique to identify the node within the
>     XML document.
>
> The admin would write policies that would say something like:
>
>     grant admingroup readprivilege
>     http://www.example.com/section01/*.xml#/a/b/c/-
>
> which would allow the admin group to read nodes below the "/a/b/c/" 
> level in section01 of www.example.com.
> So, if someone came in with an http GET on:
>
>     resource-id = http://www.example.com/section01/file01.xml#/a/b/c/d
>
> the policy above would allow access if they were in the admin group.
>
> I realize the above policy is not in xacml, however, one could fairly 
> easily have the admingroup as the subject target, the readprivilege as 
> the action target, and then write a regular expression to test the 
> resource-id against the scoped policy.
>
> Probably no need for constructing resource lists, multi requests could 
> be simply like:
>
>     resource-id = http://www.example.com/section01/file01.xml#/a/b/c/*
>
> which would effectively be a query for all the child nodes of /a/b/c 
> in the doc file01.xml.
>
> Hopefully, this is enough to make the objectives more clear, and show 
> why with this relatively limited scope of objective there is no real 
> need for document content to be provided in the requests, and policies 
> can be written such that everything can be determined from the query 
> alone.
>
> The point is that current web access control products effectively 
> provide these capabilities, and the idea is to simply provide a 
> technique to extend this type of capability to the nodes of xml documents.
>
>     Thanks,
>     Rich
>
>
> Erik Rissanen wrote:
>> 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 
>>