Re: [xacml] Concrete Proposal of ConditionReference (#7)

[Seth Proctor <Seth.Proctor@Sun.COM>]

Polar Humenn wrote:
> Oh, it has, maybe before your time. We've always held XACML to be a
> "declarative" language. And the given the same policy, and the same input,
> in all cases all PDPs should return the same value.

This is nice in theory, but it's certinaly not accurate in reality. Why? 
Because you rarely have the "same" input. Consider:

   <Request>
     <Subject/>
     <Resource>
       <Attribute DataType="...:string" AttributeId="foo">
         <AttributeValue>bar</AttributeValue>
       </Attribute>
     </Resource>
     <Action/>
     <Environment/>
   </Request>

   <Policy ...>
     ...
     <Rule RuleId="rule" Effect="Permit">
       <Condition FunctionId="...time-less-than">
         <Apply FunctionId="...time-one-and-only">
           <EnvironmentAttributeDesignator DataType="...time"
               AttributeId="...current-time"/>
         </Apply>
         <AttributeValue DataType="...time">17:00:00</AttributeValue>
       </Condition>
     </Rule>
   </Policy>

It is obviously true that the same Request run over the same policy will 
return different Results at different points. Because the RequestContext 
is "notional" and because you can always write custom, non-deterministic 
functions, you cannot make any guarentees about the restuls.

>>If I have a designator that references something that changes over the
>>course of the evaluation, I now have to keep its value constant? What
>>about if I cache a policy over many evaluations? Hrm.
> 
> The value must remain constant for the entire evaluation. This requirement
> is enforced implicitly. You apply a policy evaluation (and sub-policy
> evaluations) to the same RequestContext.

There is no such requirement in XACML. The RequestContext is amorphous, 
and therefore gives you no guarentees about anything remaining constant. 
Even if it was the same, what stops me from writing a custom function 
that uses random numbers to produce random results? Nothing. Either way, 
you cannot make these guarentees about a PDP's results.

> If what you say were really the case, we couldn't hope for
> interoperability or consistent evaluation even by the time Jenna Bush is
> ordained president of the united states.

Comments about Jenna aside (though that could be entertaining too <g>) I 
disagree. Interoperability isn't a problem, since the form of the policy 
remains the same across PDPs. Consistent evaluation is based on the 
whole of the "context handler" which is a non-static entity.

> As a policy writer, you must have the assurance that your values will not
> change at some arbitrary point in the evaluation. We enforce that by
> saying XACML is a declarative language.

Again, I disagree. As a policy writer I need no such guarentees. All I 
need to know is that I can access a particular value. In fact, I may 
choose to implement access to a particular attribute such that each 
access changes the value. I'm not making this up. I've done this. (for a 
fun exercise, think about qbits)

Now, I can understand the value in saying that for a given evaluation, 
all values will remain fixed. I can also understand the value of 
introducing a language feature that makes this contract explicit. I 
might be supportive of something like this. I do not think, however, 
that this is defined in any clear way in the current specification. I 
also don't think that it should be slipped in with a feature that is 
supposed to be providing some simple syntactic sugar. If we're changing 
the semantics of the language then fine, but let's be clear about it.

Note that a while back I suggested a change for 1.1 that required the 
current date, time, and dateTime to remain fixed for a given evaluation, 
since they're values that the PDP is required to supply and therefore 
they are special cases. I receieved a fair amount of opposition to this, 
suggesting that others also think that values and evaluation results are 
non-static for a given input.

Thoughts?


seth