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,

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,

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]