OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

[xacml] Comment on hierarchical Resource

  • 1.  [xacml] Comment on hierarchical Resource

    Posted 06-01-2004 15:14
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: [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.
    
    - 7.13.2 resource-ancestor and resource-parent
    
    Resource-ancestor and resource-parent will not be used in the case of XML
    document.
    
    - 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.
    
    
    - 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
    
    anyURI-path-match(/x/y, /x/y/z) SHALL return true
    anyURI-path-match(/x/z, /x/y) SHALL return false
    
    Any comments are welcome.
    
    Best,
    Michiharu
    
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]