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

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