Re: [xacml] wd-20 issues

From
Erik Rissanen <>
Date
2011-06-16T08:57:42+00:00
ID
Thread
Re: [xacml] wd-20 issues
Hi Rich,

    

    Yes, you are right. It seems Remon did not notice the description of
    <AnyOf> in 5.6, which is correct. 7.7 correctly says that an
    empty target will always match, though the case is not listed in the
    table. So no action should be required on this.

    

    Best regards,

    Erik

    

    On 2011-06-16 07:50, rich levinson wrote:
    
      
      Hi Erik,

      

      On the last item, I don't understand what is going to be "fixed".

      Also, I do not see any inconsistency between 5.6 and 7.7.

      I think both situations:

      
        
zero <AnyOf> elements

        
and one or more <AnyOf> elements

      
      appear to be covered in both sections 5.6 and 7.7 in a consistent

      manner. Or am I missing something?

      

          Thanks,

          Rich

      

      

      On 6/15/2011 7:11 AM, Erik Rissanen wrote:
      Remon,

        

        

        See inline. 

        

        On 2011-06-10 09:51, 
        wrote: 

        Erik, 

          

          

          -----Original Message----- 

            From: Erik Rissanen [mailto:]
            

            Sent: Thursday, June 09, 2011 11:27 AM 

            To: 
            

            Subject: Re: [xacml] wd-20 issues 

            

            5.29
              Element<AttributeDesignator> 

                  "If the Issuer is not present in the attribute
              designator, then 

            
            the matching of the attribute to the named attribute SHALL
            be governed 

            by AttributeId and DataType attributes alone." 

            - And Category. 

            
            Yes! 

          
          Also in 7.3.4 Attribute Matching. 

          

          

          5.48 Element<Result> 

              "<PolicyIdentifierList>  [Optional] 

              If the ReturnPolicyIdList attribute in the<Request> 
          is true (see section 5.42), a PDP that implements this
          optional feature MUST return a list of all policies which were
          found to be fully applicable." 

          - This prevents the PDP from skipping evaluation of policies
          that cannot affect the decision. IOW, it prevents performance
          optimizations. This is not a big deal to me, since the feature
          is optional, but maybe something to note in the implementer's
          guide? 

        
        

        The intended behavior is not how you interpret it. It says
        "which were found..." so it's simply the list of policies the
        PDP worked on during evaluation. It does not mean that the PDP
        has to figure out which policies "might have been fully
        applicable if they were to be evaluated". If you have a
        suggestion for better wording, please post it, and I can update
        this while we are fixing the other issues. 

        

        7.3.7 AttributeSelector evaluation 

              "If the DataType is not one of the primitive types listed
          above, then the return values shall be constructed from the
          nodeset in a manner specified by the of the particular
          DataType extension specification." 

          - "specified by the of the" misses a crucial noun. 

        
        

        It should just say "in a manner specified by the particular
        datatype extension specification", meaning that if you extend
        XACML with a custom data type, you also need to define (and
        implement) this constructor. 

        

        7.7 Target evaluation 

              "An empty target matches any request. Otherwise the target
          value SHALL be "Match" if all the AnyOf specified in the
          target match values in the request context." 

          - This conflicts with 5.6 Element<Target>: "For the
          parent of the<Target>  element to be applicable to the
          decision request, there MUST be at least one positive match
          between each<AnyOf>  element of the<Target> 
          element and the corresponding section of the<Request> 
          element." 

        
        

        Yes, I will fix that. Thanks for noticing. 

        

        Thanks, 

          Ray 

          

        
        

        

        ---------------------------------------------------------------------

        

        To unsubscribe from this mail list, you must leave the OASIS TC
        that 

        generates this mail.  Follow this link to all your TCs in OASIS
        at: 

        https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php