Hi Rich,
Just a small procedural nitpick. It would be good if you would update
the title of the document. It still says CD-1, while this certainly is
not CD-1, rather it is a new working draft. It could cause confusion to
have these "CD-1" versions floating around.
Best regards,
Erik
Rich.Levinson wrote:
> Note: accidentally sent out an incomplete uncirculated earlier version
> of the Hier proposal in prev email.
> http://lists.oasis-open.org/archives/xacml/200910/msg00024.html
> (i.e. disregard attachment on ref'd prev email. Instead use the one on
> current email)
>
> Attached is the correct version of the Hier proposal, which is the
> same as the one from the original email:
> http://lists.oasis-open.org/archives/xacml/200909/msg00076.html
> except w change highlighting turned off.
> Apologies for any confusion.
>
> Thanks,
> Rich
>
>
> 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
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> 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
