MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] Comment on hierarchical Resource
On 2 June, Michiharu Kudoh writes: [xacml] Comment on hierarchical Resource
> The following is my comment on hierarchical resource.
>
> - 7.13.2 xpath-node-match function
>
> While the definition of this function in 1.0 is that the input is two xpath
> expressions and the output is boolean value, the definition in the working
> draft on hierarchical resources for XACML 2.0 is that the input is one
> xpath expression and the output is applied node(s). I would prefer the
> original definition. I want to avoid to deal with "node" as a primitive
> data type of XACML because it is an implemenation-specific data type. It is
> different from other data types like integer and URI. If we remains the
> function definition as is, XACML spec does not have to worry about how to
> define node of XML documents.
I agree with this.
The most recent working draft attached to
http://lists.oasis-open.org/archives/xacml/200405/msg00104.html
does not attempt to re-define xpath-node-match. It merely refers
to the existing definition.
> - 7.13.2 resource-ancestor and resource-parent
>
> Resource-ancestor and resource-parent will not be used in the case of XML
> document.
Why not?
It seems straightforward to implement, would need to be
calculated only if the policy actually uses one of these
Attributes, and would allow XACML implementations that do not
support XPath expressions to express some useful policies with
respect to XML documents.
> - resource-id
>
> As I wrote in my previous email, I would prefer to specify two resource-id
> attribute with different data types in one request context in the case of
> XML document. For example, if the user accesses of BoD element
> (/md:record/md:patient/md:BoD) of XML document of
> http://medico.com/medicalrec/Bert, the request context would have the
> following two resource-id attributes:
>
> resource-id of http://medico.com/medicalrec/Bert with datatype anyURI
> (optional)
> resource-id of /md:record/md:patient/md:BoD with datatype xpath-expression
>
> The corresponding policy would be:
>
> if resource-id of anyURI data type is "http://medico.com/medicalrec/Bert";
> and resource-id of xpath-expression data type matches to
> "/md:record/md:patient" the access is allowed.
>
> Resource-id with any URI data type can be omitted as I wrote before. For
> example, if policy does not need to check URI, then xpath-expression match
> checking is enough. The combination of anyURI and xpath still means that
> the target resource is a single node.
>
> Therefore, the request context can have two or more resource-ids if they
> have different data types. (There is a way of passing them to PDP in one
> string using XPointer (as specified in 1.0) though.)
>
> It may contradict the description of 7.[A] requests for multiple resources.
> Thus, in the case of XML document, I think "scope" attribute should be
> applied to resource-id of xpath-expression data type. It is clear enough if
> this semantics is specified in the profile document.
If the request is for only a portion of the XML document
http://medico.com/medicalrec/Bert, then it seems incorrect to me
to say the resource-id is "http://medico.com/medicalrec/Bert"; -
that resource-id identifies the entire XML document and not just
the requested portion of it.
Would it be OK if I define a new Resource AttributeId for this
called "document-id" with type anyURI? This new Attribute would
be specified as containing the URI of the entire document of
which the requested resource is a part. This seems more clear to
me.
> - 7.13.2 anyURI-equal/match function
>
> I would like to see the definition of anyURI-match function that receives
> two anyURI values and returns true
> if "scheme" exists, then the scheme of the first argument and the scheme of
> the second argument must be the same
> if "authority" exists, then the authority of the first argument and the
> authority of the second argument must be the same
> if "path" exists, then the path of the first argument must be equal or the
> subset of the second argument.
>
> For example,
> anyURI-match(http://abc, http://abc) SHALL return true
> anyURI-match(//abc, //abc) SHALL return true
> anyURI-match(/x/y/z, /x/y/z) SHALL return true
> anyURI-match(http://abc, //abc) SHALL return false
> anyURI-match(//abc, /x/y/z) SHALL return false
>
I do not see any conflict between these semantics and rfc2396
(URI Generic Syntax), so I support extending "anyURI-equal" and
"anyURI-match" as above. Partly, this involves supporting
matching of relative URIs as well as absolute URIs.
> anyURI-path-match(/x/y, /x/y/z) SHALL return true
> anyURI-path-match(/x/z, /x/y) SHALL return false
You did not describe "anyURI-path-match" above. Why can't this
function be part of "anyURI-match" with Tim's proposed "*"
wildcard character?
If relative URIs are supported, then using his proposal:
anyURI-match(/x/y/*, /x/y/z) SHALL return true
anyURI-match(/x/z, /x/y) SHALL return false
> Any comments are welcome.
>
> Best,
> Michiharu
Thank you for your comments. Additional comments are welcome.
Anne
--
Anne H. Anderson Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]