Re: [xacml-comment] Specification of extended indeterminate in combiningalgorithms is incomplete

Thanks Bill,

    

    In that case, what about if we agree on the next call for the
    minutes on the intended meaning, which can stand as implementation
    advice to users and vendors?

    

    Best regards,

    Erik

    

    On 2011-03-14 16:25, bill parducci wrote:
    
      
Unfortunately, underspecification typically doesn't qualify
        as errata. Any material change to the meaning will require a
        formal update. 

        

        

        

        
b

        

        

      

      

        On Mar 14, 2011, at 4:37 AM, Erik Rissanen <>
        wrote:

        

      

      
        
 Hi Matthew,

          

          For convenience to all, the extended indeterminate is defined
          in section C.1 of the spec. http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.html#_Toc265751171
          (link to the current CS version).

          

          You are right that it's underspecified now that I read it
          again. Specifically, as you say, the following is not well
          defined:

          

          - How shall an "Indeterminate" returned form a "normal"
          algorithm be treated by an "extended" algorithm?

          

          The intent has been that a "legacy" indeterminate corresponds
          to a Indeterminate{DP} since the legacy algorithms do not
          track the different cases. It should have been written out.

          

          Regarding the reverse question, what a legacy algorithm should
          do with an extended value, then the legacy algorithm would
          ignore the additional indeterminate value, and treat it just
          as a plain Indeterminate. I think that is what the spec
          implies as it is, but it should have been explicitly spelled
          out.

          

          Regarding your question about the target, I agree that it's
          underspecified and there are also a couple of sensible things
          that could be done. I guess the most sensible thing would be
          that depending on what the combination algorithm returns
          (Permit, deny, a variant of indeterminate), you would return
          the appropriate extended value for the policy/policy set as a
          whole if there is an Indeterminate in the target.

          

          Not sure how to fix this in practice as errata. Hal?

          

          Best regards,

          Erik

          

          

          On 2011-03-11 21:07, Wood, Matthew D wrote:
          
            
            

              
The 10/8/2010 committee specification
                (using urn:oasis:names:tc:xacml:3.0:core:schema:wd-17
                namespace) appears to be incomplete with respect to
                extended indeterminate states in the combining
                algorithms. The new combining algorithms are defined
                entirely in terms of extended indeterminate, but there
                are cases where extended indeterminate values are not
                available:

              
-          Algorithms

                present since the XACML 1.x, whether or not they are
                marked for deprecation, are only specified in terms of
                indeterminate

              
-          Indeterminate

                results from evaluating a policy target

              
There are no indications about how to
                handle unextended indeterminate values in the new
                algorithms or how an extended indeterminate should be
                propagated through pre-3.0 algorithms.

              
 

              
For the first-applicable combining
                algorithms, it seems reasonable to propagate the variant
                of indeterminate as the result of the algorithm on lines
                5646 and 5685 for the rule and policy combining
                algorithms, respectively. The others are unclear to me,
                though specification about how to handle unextendend
                indeterminate results in the new algorithms would also
                solve the problem in a seemingly simpler manner.

              
 

              
This issue makes it unclear about
                what should be proper conforming behavior.

              
 

              
Another minor omission is lack of
                explicit indication that obligations and advice should
                be handled according to section 7.16 after the
                pseudo-code for the first-applicable rule combining
                algorithm, as appears for all other rule and policy
                combining algorithms.

              
 

              
Matthew Wood

              
Sr. Software Engineer

              
SSG Software Pathfinding Initiative