I agree with Paul on that regexp is a poor choice for working with XML
content. But for the sake of moving forward, I could live with an
optional section in the spec and let the market decide whether it is
worth using.
Best regards,
Erik
Tyson, Paul H wrote:
> I still can find no compelling reason to introduce this into the
> standard. Any enterprise could certainly adopt this system of
> resource identification without violating the XACML specification. I
> cannot see any advantage in doing this, but I believe Rich when he
> says there may be highly constrained situations that force one to this
> type of solution. That is not a good enough reason to put it in the
> standard, though.
>
> To address some specific points:
>
> 1. XPath performance overhead. I don't know what others have
> experienced, but I have used saxon xslt engine for years, and simply
> cannot slow it down no matter how complex my xpath expressions are, or
> how large the input documents are. I don't know what xpath engines
> are commonly used in XACML implementations, but poor performance is
> not an inherent feature of xpath processing. In the case of multiple
> authorization decisions on a single document, it would be a very naive
> implementation that actually re-parsed the document for every decision.
>
> 2. Paradigm shifting: Attribute(Designator|Selector), xpath vs.
> regex. Really, who *likes* regex? ;-) XACML is an XML application,
> therefore the first and favored approach should be xpath. It's nice
> to be able to use regex when necessary, but I have never seen a case
> where it is the best first choice in XML processing (except for
> datatyping and value checking, but those areas are outside the domain
> of xpath). A developer who knows regex better than xpath would want
> to use regex first, but xpath is a much more natural fit with XML.
>
> 3. Not wanting to expose entire XML document to PDP. If this is a
> hard constraint, there are other architectural alternatives. Take the
> book catalog use case. For my money, I would do something like this
> before using the alternative URI representation:
> a. Query book database for candidate records
> b. Send multi-decision request with attributes like ((user=Jones),
> (type=book, author=Jones, price=50),
> (type=book,author=Smith,price=30), ...)
> c. Receive results
> d. Form XML for delivery to user, based on results.
>
> This model would work for all cases where the XML is manufactured from
> database or other backend sources. Just move the authorization step
> ahead of the XML creation.
>
> The book use case does not actually depend on any hierarchical
> relations for the decision, so it is not the best example.
>
> Regards,
> --Paul
>
> ------------------------------------------------------------------------
> *From:* Rich.Levinson [mailto:]
> *Sent:* Monday, October 12, 2009 22:02
> *To:* xacml
> *Subject:* [xacml] Proposal to address issue 11, and thoughts on
> whether it is advisable or not to separate out sections of hier,
> mult to a new profile
>
> 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
>
