OASIS eXtensible Access Control Markup Language (XACML) TC

Re: [xacml] [Model] Composition Use Case

  • 1.  Re: [xacml] [Model] Composition Use Case

    Posted 12-17-2001 09:30
    anne's [test] case, and those that have preceded it have raised those 
    points that i think are relevant to the example that i through out on 
    the list some time ago. so instead of adding another log to the fire i 
    have just jotted down a couple of comments.
    
    /*
    1. Ability to describe Matching Rules for attributes (for
        example, does "A@EnergyInfoAdmin.doe.gov" match "*.doe.gov").
    */
    
    this is really the key requirement in my example: pattern matching. the 
    only difference here from what i tossed out was that my 'case' used this 
    against payload (content) as well has requester information. since i 
    believe that payload is just another field i think that the generalized 
    requirement for pattern matching meets the requirement. as pointed out 
    earlier by a couple of people, i believe that regular expressions should 
    be used as the basis for patterning.
    
    /*
    2. Ability to apply multiple policies, possibly from different
        sources, to a single resource.
    */
    
    i think thst this has been designated or assumed in just about all of 
    our discussions (at least by me :o)
    
    
    /*
    3. Ability to use arbitrary attributes, such as clearance level,
        in policy statements.  These may be defined by the Policy
        Issuer.  There must be a way for the PDP to obtain the
        definition and matching rule semantics associated with the
        attribute.
    */
    
    i believe that this requirement ultimately speaks to the point that [i 
    think] tim m. brought up and that is the need for discrete policy 
    namespace assignment. since my number one goal is interoperabilty, the 
    word 'arbitrary' scares me and i think that resolving this issue will 
    end up being *the* key aspect of our architecture.
    
    /*
    
    a. What if, instead of "FALSE", a sub-policy can return
       "DenyAccess", and this means that a result of "DenyAccess"
       must be returned from the top-level policy?
    
    */
    
    this is a very interesting requirement and one that i don't think that 
    we have touched on directly (having missed the last two policy concalls, 
    i could be wrong): non boolean policy resolution. i look forward to 
    seeing this one on a whiteboard! :o)
    
    b