[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Comment on hierarchical Resource
Hi, Anne
>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.
OK. I am not clear on the sentence that "This function MAY be used with the
higher-order bag functions described in Appendix A.3.12". In my
understanding, this function only returns Boolean and nothing to do with
bag. Or I miss something?
>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.
This slipped out of my head. So you want to specify policy for XML
documents without XPath support. Correct?
If so, resource-ancestor etc. would be useful.
>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.
Since "http://medico.com/medicalrec/Bert"; is meta info of the embedded XML
doc, then it might be appropriate to create a new attribute for this like
"document-id" as you wrote. I reconsider this.
>You did not describe "anyURI-path-match" above. Why can't this
>function be part of "anyURI-match" with Tim's proposed "*"
>wildcard character?
I did not read Tim's proposal. I will comment after I read it.
Best,
Michiharu
Anne Anderson
<Anne.Anderson@Su
n.COM> To
XACML TC
2004/06/02 02:49 <xacml@lists.oasis-open.org>
cc
Please respond to Subject
Anne.Anderson 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
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]