Re: [xacml] Is the choice element in Policy correct

Hi Rich,

    

    Seems good to me. We can put the advisory note in the planned
    implementors guide. I thought someone was collecting these on the
    wiki for the guide. If there is no such wiki, you could easily
    create a page.

    

    Best regards,

    Erik

    

    On 2012-01-30 18:49, rich levinson wrote:
    
      
      
      Hi Erik,

      

      The impression I am getting is that the intent of the spec is that

      any of these 4 elements can occur any number of times (0->n),

      and the fact that meaningless Policies (i.e. Policies w no Rules)

      can be created is not a concern, because they can be used as

      placeholders for certain implementation strategies. 

      where the term "meaningless" refers to the fact that

        such Policies play no role in the decision process,

        and their presence may be ignored by a PDP.

      
      Also, the fact that 2 of them have minOccurs="0" and

      the other 2 have default minOccurs="1" is a pointless

      distinction, because the fact that any element has

      minOccurs="0" implicitly overrides the minOccurs of

      any other element within the choice group.

      

      It would seem to me that at a minimum, we could include

      an advisory note to developers that a PDP may ignore

      a Policy that contains no Rules, since there is no point

      from a XACML functional perspective to provide any logic

      to do anything specific with such Policies.

      

      Such an approach would remove any questions from developers,

      and could leave the schema unchanged.

      

      Thoughts?

      

          Thanks,

          Rich

      

      

      

      

      On 1/30/2012 5:25 PM, Erik Rissanen wrote:
      
        
        Hi Rich,

        

        Actually, I think I was mistaken in my email. If the schema is
        like it is:

        

        <xs:choice maxOccurs="unbounded">

            <xs:element ref="xacml:CombinerParameters"
        minOccurs="0"/>

            <xs:element ref="xacml:RuleCombinerParameters"
        minOccurs="0"/>

            <xs:element ref="xacml:VariableDefinition"/>

            <xs:element ref="xacml:Rule"/>

        </xs:choice>

        

        Then a completely empty policy is possibly since you can make a
        choice of a "non-existing parameter". So there really is no
        issue here. Agreed, the schema could be a bit prettier, but it
        works.

        

        Best regards,

        Erik

        

        On 2012-01-30 10:14, Erik Rissanen wrote:
        
          
          Hi Rich,

          

          I think the intent has always been to allow empty policies.
          It's useful especially for automatically generated policies to
          be able to generate empty policies as a special case of a
          general scheme for generating a full policy set.

          

          So I would not want to restrict the schema like your first
          bullet point. Rather the change to do would be to add a
          minOccurs="0" to the choice, but since it is already possible
          to generate a policy with no rules in the current schema (by
          putting a a dummy combiner parameter), I don't think it's a
          big deal.

          

          Best regards,

          Erik

          

          On 2012-01-29 19:15, rich levinson wrote:
          
            
            
            Hi Erik,

            

            At this point we are simply trying to determine what the
            schema should be,

            in the sense that if it was reflecting the intended
            behavior, what changes

            would be appropriate.

            

            For example it would seem the appropriate changes might be:

            
              
A Policy must have one or more Rules.

              
A Policy may have zero or more VariableDefinitions

              
A Policy may have zero or one CombinerParameters

              
A Policy may have zero or one RuleCombinerParameters

            
            If these are the actual requirements that are intended, or
            if some

            other specific requirements are more accurate or
            appropriate, then

            the purpose of the issue being raised is to determine what
            are the

            correct requirements.

            

            Once the requirements are established, then we can evaluate
            what,

            if any, impact that might have on the schema, and whether
            the

            TC thinks the schema should be changed.

            

            At present, it appears that the current schema does not
            reflect

            any kind of plausible real requirements, and this represents

            a problem for developers using the specification to build
            products,

            because they may be uncertain how to handle the use cases
            that

            are made possible w the current schema.

            

                Thanks,

                Rich

            

            

            On 1/27/2012 6:10 PM, Erik Rissanen wrote:
            
              
              Hi Rich,

              

              I don't think there is anything which needs to be changed
              here. It's true that the schema is a bit weird in this
              respect. It's a carry over from 2.0, and does not
              represent any practical concern.

              

              Empty policies are fine I think, though it does not really
              make sense to have an empty policy with variables since
              there would be no rule to use them.

              

              But there is not really any issue in how to interpret any
              combination which the schema allows and there is no reason
              for a product to produce meaningless policies.

              

              I would say that we keep it as it is.

              

              Best regards,

              Erik

              

              

              On 2012-01-24 07:23, rich levinson wrote:
              
                
                To TC:

                

                We have been looking at the xsd for Policy and there is
                a central

                "choice" element that does not appear correct, although
                for

                mainstream Policies it probably does not show up.

                

                The choice element is the following:

                 2028

                  <xs:choice maxOccurs="unbounded">

                      <xs:element ref="xacml:CombinerParameters"
                  minOccurs="0"/>

                      <xs:element ref="xacml:RuleCombinerParameters"
                  minOccurs="0"/>

                      <xs:element ref="xacml:VariableDefinition"/>

                      <xs:element ref="xacml:Rule"/>

                  </xs:choice>

                
                This is the construct that allows multiple Rules in a
                Policy, which, looking at

                the Rule element alone, seems ok, as default is
                minOccurs="1", and it

                inherits maxOccurs="unbounded" from the choice element
                itself.

                

                However, very little else about this element appears to
                make sense:

                
                  
Since this is a choice element, w minOccurs="1",
                    one could choose any

                    of the other 3 elements and nothing else, and the
                    result would be a

                    Policy with zero Rules. Does this make sense?

                  
With zero Rules, even if you used the Policy to
                    define VariableDefinitions,

                    they cannot be referenced outside the Policy, and
                    since there are no

                    Rules in the Policy, there is nothing that would
                    ever use the

                    VariableDefinitions.

                  
Does it make sense to have multiple instances of
                    either CombinerParameters

                    or RuleCombinerParameters? i.e. can't all the
                    parameters be put in one

                    element in both cases? If not then why are these
                    elements in the choice

                    block that allows unbounded instances?

                
                Please advise as to whether the above interpretation is
                accurate. If so, we would

                like to consider raising this as an issue for action.

                

                    Thanks,

                    Rich