Re: [xacml] Comment on hierarchical Resource

[Anne Anderson <Anne.Anderson@Sun.COM>]

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