OASIS eXtensible Access Control Markup Language (XACML) TC

Re: [xacml] CR 144: function "present" needs to be fixed.

  • 1.  Re: [xacml] CR 144: function "present" needs to be fixed.

    Posted 10-24-2002 14:04
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

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


    Subject: Re: [xacml] CR 144: function "present" needs to be fixed.


    
    Okay, I'm in trouble on this "*-is-present" stuff.
    
    In looking in the schema, I found out that I probably messed up the
    subject-attribut-*-present functions by not having an argument that
    states the value of the subject-category attribute.
    
    I also have a problem with the subject-attribute-*-present-where
    functions.
    I specify that they will take <SubjectMatch> elements as arguments in the
    <Apply>. However, that does NOT fit the evaluation strategy very well, as
    these elements return booleans, and to be consistent with the generic
    function application evaluation model, they should be evaluated
    independantly as arguments. Basically, they are evaluated without concern
    of being limited to the same subject. We somehow have to bring the
    evaluation of the equivalent of subject match into the function.
    
    So, unfortunately, because of multiple subjects, this approach complicates
    matters to no end for the function predicates that need to figure this
    out, as for subject-attribute-is-present-where I would have to specify
    something silly like:
    
    For each subject match we would add to the
    subject-attribute-is-present-where function, sets of four arguments, each
    of which the first is the MatchId, the second is the attribute name, the
    third is the data type, and the fourth is the matching value. (Yuch!)
    
    My conclusion: Since attributes are retrieved by different schema
    elements, it seems most logical to make their "is-present" counterparts
    schema elements as well, using much of the same machinery already in
    place. It would be easy to add these as element of the
    AttributeDeignator/Selector/Type complex types we ALREADY have defined:
    
    So, I think a better approach would be to add the following elementsto the
    schema with the semantics I proposed in the previous iterations.
    
    These elements woud be element instances of the <AttributeDesignatorType>:
    
    ActionAttributeIsPresent      ActionAttributeMustBePresent
    ResourceAttributeIsPresent    ResourceAttributeMustBePresent
    EnvironmentAttributeIsPresent EnvironmentAttributeMustBePresent
    
    These elements would be element instances of the
    <SubjectAttributeDesignatorType>:
    
    SubjectAttributeIsPresent     SubjectAttributeMustBePresent
    
    These elements would be element instances of the
    <SubjectAttributeDesignatorWhereType>:
    
    These elements can be element instances of the <AttributeSelectorType>:
    
    AttributeIsPresent            AttributeMustBePresent
    
    I can modify the document with Word97 and give these sections to the list
    if one would like?
    
    -Polar
    
    


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


    Powered by eList eXpress LLC