Hi Rich,
Still, it should cover something which the xpath approach does not
cover, or do something better. Could you elaborate what it does beyond
xpath? So far I have only seen examples of how the URI approach can
replicate the xpath approach.
Best regards,
Erik
Rich.Levinson wrote:
> Hi Erik,
>
> The intent of the proposal is not to replace or be better than XPath,
> but to be an "alternative representation" for node identification as
> described in section 2.0 of the profile, which if we included in the
> profile as suggested in section 2.2.1, presumably would then be a
> "recommended alternative representation".
>
> The reason for the suggestion was to address the requirements
> specified in issue 11, which contained a recommended syntax that did
> not incorporate namespaces. By using the Clark notation for the
> namespaces, the syntax in issue 11 can be directly incorporated to the
> URI scheme as described in the proposal.
>
> Once the syntax is in place then the same kinds of regexp-scoped
> Policy's can be written for XML nodes as for file system and URL
> resources.
>
> Assuming the syntax and proposal is correct, it may be a useful
> alternative representation in some situations, particularly where it
> may be an objective to identify all resources w URIs, and/or where the
> mixed XACML/XPATH syntax is a concern wrt Policy specification.
>
> Thanks, Rich
>
>
> Erik Rissanen wrote:
>> Hi Rich,
>>
>> Some of the reasons why an XPath approach could be better are:
>>
>> 1. XPath contains many functions and other capabilities, which might
>> not be as easily available in the URI based approach.
>>
>> 2. The TC would avoid the effort to define the URI approach. We would
>> need to improve the xpath approach instead, but I suspect that the
>> effort is smaller since we can reuse so much from xpath, compared
>> with a wholly new URI based approach.
>>
>> 3. It is likely that an XML resource is already available in XML
>> form, so an xpath implimentation can be applied to it directly, while
>> the URI approach requires a transformation, which could degrade
>> performance.
>>
>> Note that it is not true that the whole XML has to be repeated for
>> each resource since multiple <Attributes> elements are not required
>> with the xpath approach, and with XACML 3.0 it is possible to reuse
>> the same <Content> document for all the multiple queries.
>>
>> Best regards,
>> Erik
>>
>> Rich.Levinson wrote:
>>>
>>> Hi Jan, et al,
>>>
>>> I have had a busy week and not been able to respond until now,
>>> however, looking over all the subsequent emails to the one to which
>>> this is a response (
>>> http://lists.oasis-open.org/archives/xacml/200909/msg00081.html
>>> ), it appears to me that there are still unresolved issues, and from
>>> my perspective, there are some assertions made, with which I
>>> disagree, about AttributeDesignators, which I thought my suggested
>>> URI scheme would address, but apparently it either needs further
>>> explanation or I am missing something that I have not yet
>>> understood. In any event I would very much like to determine whether
>>> these assertions are true or false in order that the TC be of a
>>> single mind when comparing the capabilities of AttributeSelectors
>>> and AttributeDesignators.
>>>
>>> The assertion with which I disagree is that the AttributeDesignators
>>> cannot do what the AttributeSelectors can do because the
>>> AttributeDesignators lose the hierarchical structure. My response is
>>> that if you don't throw away the hierarchical structure when
>>> creating your AttributeDesignators then this perceived problem does
>>> not exist.
>>>
>>> If I am wrong about this, I will accept that, however, I do not
>>> believe that my approach to the AttributeDesignators has been
>>> considered on its merits yet, and I will try to be totally explicit
>>> in this email, and I will show how I think Jan's proposed solution
>>> can be completely done using only AttributeDesignators and regexp
>>> string matching.
>>>
>>> Having been thru some lengthy discussions earlier this year on the
>>> hierarchical profile, I became quite sensitive to the node naming
>>> issue, and one of the results of those earlier discussions was that
>>> if hierarchical URIs are used to name nodes, that these names
>>> contain within them the navigation necessary to locate the node, so
>>> that using these names outside of an XML document does not lose the
>>> structural relationships.
>>>
>>> Using James Clark's universal name syntax ("{namespace}elementname"
>>> http://www.jclark.com/xml/xmlns.htm) combined with a transform to
>>> replace the xml document with a list of name/value pairs (there are
>>> several XML to JSON xslt transformers available free, which I expect
>>> could readily be adapted to produce name/value pairs in the format
>>> below), where each element and attribute is identfied by its full
>>> path expressed as universal element names. For example, assuming the
>>> document you gave as an example had a namespace = "foo":
>>>
>>> <objects xmlns:="foo">
>>> <book>
>>> <title>xxx</title>
>>> <author>Bob</author>
>>> <id>100</id>
>>> <price>30</price>
>>> <book-content>.....</book-content >
>>> <book>
>>> <book>
>>> <title>yyy</title>
>>> <author>Alice</author>
>>> <id>200</id>
>>> <price>80</price>
>>> <book-content >...</book-content >
>>> <book>
>>> </objects>
>>>
>>> The above document would first be transformed to the following set
>>> of name value pairs (ignoring whitespace):
>>> /{foo}objects = ""
>>> /{foo}objects/{foo}book[1] = ""
>>> /{foo}objects/{foo}book[1]/{foo}title = "xxx"
>>> /{foo}objects/{foo}book[1]/{foo}author = "Bob"
>>> /{foo}objects/{foo}book[1]/{foo}id = "100"
>>> /{foo}objects/{foo}book[1]/{foo}price = "30"
>>> /{foo}objects/{foo}book[1]/{foo}content = "..."
>>> /{foo}objects/{foo}book[2] = ""
>>> /{foo}objects/{foo}book[2]/{foo}title = "yyy"
>>> /{foo}objects/{foo}book[2]/{foo}author = "Alice"
>>> /{foo}objects/{foo}book[2]/{foo}id = "200"
>>> /{foo}objects/{foo}book[2]/{foo}price = "80"
>>> /{foo}objects/{foo}book[2]/{foo}content = "..."
>>>
>>> The next step is to define resources, which for this use case would
>>> be done based on multiple resource profile, where we would have 2
>>> resources, using Erik's shorthand:
>>> <Resource>resource-id=/{foo}objects/{foo}book[1]</Resource>
>>> <Resource>resource-id=/{foo}objects/{foo}book[2]</Resource>
>>>
>>> The next step is to create xacml attributes for these resources
>>> using the full universal names as AttributeIds (again w some
>>> shorthand), resulting in the following 2 requests:
>>> (Note: since AttributeId requires anyURI datatype, the following
>>> percent-encoding must be applied to the AttributeId values:
>>>
>>> * { -> %7B
>>> * } -> %7D
>>> * [ -> %5B
>>> * ] -> %5D )
>>>
>>>
>>> <Request>
>>> <Subject>subject-id="Bob"</Subject>
>>> <Resource>
>>> <Attribute>AttributeId="resource-id"
>>> value="/{foo}objects/{foo}book[1]"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dtitle"
>>> value = "xxx"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dauthor"
>>> value = "Bob"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Did"
>>> value = "100"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dprice"
>>> value = "30"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dcontent"
>>> value = "..."</Attribute>
>>> </Resource>
>>> </Request>
>>>
>>> <Request>
>>> <Subject>subject-id="Bob"</Subject>
>>> <Resource>
>>> <Attribute>AttributeId="resource-id"
>>> value="/{foo}objects/{foo}book[2]"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dtitle"
>>> value = "yyy"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dauthor"
>>> value = "Alice"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Did"
>>> value = "200"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dprice"
>>> value = "80"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dcontent"
>>> value = "..."</Attribute>
>>> </Resource>
>>> </Request>
>>>
>>> All the above processing to create the requests is done in the
>>> ContextHandler, then the requests are submitted one at a time to the
>>> PDP.
>>> Now the rule that gets applied to each of these requests is the
>>> following:
>>>
>>> <Rule effect=Deny>
>>> Target:
>>> reg-exp-string-match(resource-id, /{foo}objects/{foo}book\[\d+\]
>>> Condition:
>>> AttributeDesignator(AttributeId =
>>> function:string-concatenate(resource-id, /%7Bfoo%7Dprice) > 50 and
>>> AttributeDesignator(AttributeId =
>>> function:string-concatenate(resource-id, /%7Bfoo%7Dauthor) =
>>> AttributeDesignator(subject-id)
>>> </Rule>
>>>
>>> Unless I am mistaken, all the logic and structure is retained and it
>>> has been done purely w AttributeDesignators and regexp.
>>>
>>> Assuming the above is correct, then the points I made about the
>>> advantages over XPath (for an enterprise looking to use only URIs to
>>> identify attributes):
>>>
>>> 1. The XML document does not need to be passed in with the request.
>>> There is no node collection, only string operations.
>>> 2. For very large XML documents, say a catalog of 10,000 books, each
>>> book is processed individually independent of the other books, as
>>> compared to the XPath case, where one might expect the whole
>>> document has to get parsed for each of the 10,000 individual
>>> requests.
>>> 3. There is no paradigm shifting, or what I believe was referred to
>>> in the discussion as "shifting semantics between XPath and XACML
>>> in terms of representing the policies.
>>>
>>> Again, assuming the above is correct, I am not assuming this will be
>>> desirable for everyone, however there may very well be organizations
>>> for whom the advantages of this approach are decisive.
>>>
>>> A couple other points are that
>>>
>>> * the "unsightliness" of the AttributeIds and the
>>> AttributeDesignators can be "covered" up by policy tools that
>>> facilitate defining policies based on XML Schemas, and can keep
>>> all the encoding details transparent to the policy designers.
>>> * the issue about basing policies on the structure of XML documents
>>> is a legitimate concern, however, if structure of documents
>>> change, then a legitimate case could probably made that the
>>> namespace associated with that structure should also change, which
>>> would mean the policy tools would need to be able to facilitate
>>> upgrading of policies to new namespaces based on new revs of the
>>> schemas.
>>>
>>> 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
