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
Michiharu,
Thank you very much for your review.
On 2 June, Michiharu Kudoh writes: Re: [xacml] Comment on hierarchical Resource
> >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?
Since an <AttributeSelector> or <ResourceAttributeDesignator>
returns a "bag" of Attributes, it is most natural to use the
xpath-node-match function with a higher-order bag function as
follows:
<Apply FunctionId="any-of">
<AttributeValue DataType="string">
policy-needed value goes here
</AttributeValue>
<AttributeSelector RequestContextPath="path to
corresponding node here"
DataType="string" />
</Apply>
The "string-is-in" function could also be used.
Otherwise, you have to surround the <AttributeSelector> with an
Apply element using the "string-one-and-only" function.
> >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.
The current proposal, I think, is a combination of several
e-mails. Here is a summary.
--------------------------
Original proposal by Tim
(http://lists.oasis-open.org/archives/xacml/200405/msg00075.html):
Colleagues - Here is a draft of the proposed URL-match function (with help
from JSR 115). All the best. Tim.
urn:oasis:names:tc:xacml:2.0:function:url-match
This function takes two arguments of type
http://www.w3.org/2001/XMLSchema#anyURI and SHALL return an
http://www.w3.org/2001/XMLSchema#boolean. It SHALL return "True" if all of
the following conditions hold. Otherwise, it SHALL return "False".
1. The scheme part of both arguments SHALL be the same and SHALL be
either "http", "https" or "file". The scheme parts MAY be compared using
urn:oasis:names:tc:xacml:1.0:function:string-equal, once both parts have
been normalized to upper-case.
2. The authority part of the first argument SHALL match the authority
part of the second argument by either
urn:oasis:names:tc:xacml:2.0:function:ipAddress-match or
urn:oasis:names:tc:xacml:2.0:function:dnsName-match.
3. The path part of the first argument SHALL match the path part of the
second argument in at least one of the following ways.
3a The path part of the first argument matches the path part of the
second argument by urn:oasis:names:tc:xacml:1.0:function:string-equal.
3b The path part of the first argument is the string "/*".
3c The path part of the first argument starts with "/" and ends with
"/*" and the path part of the second argument starts with the same string as
the path part of the first argument, minus its last 2 characters, and the
next character of the path part of the second argument, if present, is "/".
3d The path part of the first argument starts with "*." and the path
part of the second argument ends with the same string as the path part of
the first argument, minus its first 2 characters.
3e The path part of the first argument is the special string, "/",
which matches all other paths.
--------------------------
In a subsequent e-mail:
Guys - "*" is an unreserved character, which IS allowed in a URI. We should
probably specify that "*" be escaped, unless it is the wild-card. All the
best. Tim.
--------------------------
Then, in Minutes of 20 May 2004 XACML Focus Group
(http://lists.oasis-open.org/archives/xacml/200405/msg00090.html):
There was general agreement that Tim's URL match function
should be extended to cover all URIs, and not just URLs.
Since RFC2396 specifies that "/" is reserved as a separator
between hierarchical components of the identifier, this means
that matches can always be by component, regardless of the
actual component syntax for various URI schemes.
--------------------------
Thanks again,
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]