[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, 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]