OASIS eXtensible Access Control Markup Language (XACML) TC

Expand all | Collapse all

Groups - Hierarchical Resource Profile WD 6 (xacml-3.0-hierarchical-v1-spec-wd-06-en.doc) uploaded

  • 1.  Groups - Hierarchical Resource Profile WD 6 (xacml-3.0-hierarchical-v1-spec-wd-06-en.doc) uploaded

    Posted 03-25-2009 21:35
    I forgot to update the table of contents in the previous version
    
     -- Hal Lockhart
    
    The document revision named Hierarchical Resource Profile WD 6
    (xacml-3.0-hierarchical-v1-spec-wd-06-en.doc) has been submitted by Hal
    Lockhart to the OASIS eXtensible Access Control Markup Language (XACML) TC
    document repository.  This document is revision #1 of
    xacml-3.0-hierarchical-v1-spec-wd-06-en.doc.
    
    Document Description:
    
    
    View Document Details:
    http://www.oasis-open.org/committees/document.php?document_id=31829
    
    Download Document:  
    http://www.oasis-open.org/committees/download.php/31829/xacml-3.0-hierarchical-v1-spec-wd-06-en.doc
    
    Revision:
    This document is revision #1 of
    xacml-3.0-hierarchical-v1-spec-wd-06-en.doc.  The document details page
    referenced above will show the complete revision history.
    
    
    PLEASE NOTE:  If the above links do not work for you, your email application
    may be breaking the link into two pieces.  You may be able to copy and paste
    the entire link address into the address field of your web browser.
    
    -OASIS Open Administration
    


  • 2.  Re: [xacml] Groups - Hierarchical Resource Profile WD 6 (xacml-3.0-hierarchical-v1-spec-wd-06-en.doc)uploaded

    Posted 03-26-2009 03:45
    
    
      
      
    
    
    Hi Hal,

    I have had a chance to do a preliminary analysis of the revision you are proposing and have a few comments.

    First, I think there are a couple of typos left over from the version 3 that we should correct, which I believe should be non-controversial in nature:
    1. Section 2.2, line 221, where it says ":", I believe it should say "://".
    2. I have looked over RFC 2396, section 3, and I believe that in section 3, when they say the following that it means that we do not have to say "hierarchical with slashes":
      • "URI that are hierarchical in nature use the slash "/" character for separating hierarchical components."
      also RFC 1738 defines the file: scheme as "file://<host>/<path>", which fits the overall original 2.2 structure of "<scheme>://<authority>/<path>" (where I have included the "//" indicated in 1 above.
      i.e. I do not understand your distinction on line 219-220 of "hierarchical with slashes" vs. "hierarchical using slashes", of which you put http in the latter category, then seem to exclude http by saying only the schemes characterized by "with slashes". i.e. is the point of this to exclude http because that's how I read it, and if so, why? (ok, maybe this one might be controversial depending on the answer :) )
    3. Section 4.1, line 444: where it says "Section 3.2" it should say "Section 2.2".
    4. Section 4.3, line 471: where it says "1.0:function:regexp-uri-match" it should say "2.0:function:anyURI-regexp-match".
    So, the rest of my comments are in section 3.3, which used to be section 3.2.
    I think I see a possible path toward closure there, so rather than dealing with details, let me take a higher level perspective.
    The "general process" on lines 374-380 may be able to pin things down, but I have some questions about the way it is currently phrased:
    1. I am not sure what "collect all the hierarchies" in step 1 means nor "discard any hierarchies" in step 2. I understand the intent, but a "hierarchy" is a collection of nodes, and we are dealing with one node to start, the requested node, which can belong to some hierarchies and not to others. I think we need a notion of the "identifier" associated with a specific hierarchy, and the requested node will have a set of identifiers which are effectively membership identifiers within specific hierarchies.
    2. With the notion of identifiers associated with hierarchies, the requested node has a list of identifiers associated with (has a one to one relation with) a list of hierarchies.
    3. Now, every node in the process will have its own list of identifiers/hierarchies of which it is a member.
    4. So, if based on the above notion, we could then say that what we mean by "discard any hierarchies of which the node in question is not actually a member", is that when ancestor nodes are processed that "only the identifiers of which the requested node is a member will be used" then I think things will be pinned down a little more clearly.
    5. Finally, I think the terminology of the "general process" has to be carried directly into the 4 bullets so that there is no ambiguity between the "general process" and the "bullets".
    Thanks,
    Rich




    hal.lockhart@oracle.com wrote:
    20090325213457.12912.qmail@eos.oasis-open.org" type="cite">
    I forgot to update the table of contents in the previous version
    
     -- Hal Lockhart
    
    The document revision named Hierarchical Resource Profile WD 6
    (xacml-3.0-hierarchical-v1-spec-wd-06-en.doc) has been submitted by Hal
    Lockhart to the OASIS eXtensible Access Control Markup Language (XACML) TC
    document repository.  This document is revision #1 of
    xacml-3.0-hierarchical-v1-spec-wd-06-en.doc.
    
    Document Description:
    
    
    View Document Details:
    http://www.oasis-open.org/committees/document.php?document_id=31829
    
    Download Document:  
    http://www.oasis-open.org/committees/download.php/31829/xacml-3.0-hierarchical-v1-spec-wd-06-en.doc
    
    Revision:
    This document is revision #1 of
    xacml-3.0-hierarchical-v1-spec-wd-06-en.doc.  The document details page
    referenced above will show the complete revision history.
    
    
    PLEASE NOTE:  If the above links do not work for you, your email application
    may be breaking the link into two pieces.  You may be able to copy and paste
    the entire link address into the address field of your web browser.
    
    -OASIS Open Administration