OASIS eXtensible Access Control Markup Language (XACML) TC

All,

I have been considering optimization of XACML evaluation and one issue 
which the spec is unclear on is out of order evaluation.

I thought that the spec says somewhere that the PDP is allowed to do 
processing in any way as long as the results are identical to the spec, 
but I cannot find that anywhere now when I tried to look for it. I think 
we should insert this in the normative text of the specification.

I would also like to say something about side effects. None of the 
standard XACML functions have side effects, but it is conceivable that 
an XACML extension could have side effects. I would like to state in the 
normative text that any extensions and policies may not assume any 
particular order of execution with respect to side effects.

I propose that we add a new section 7.16 in the XACML 3.0 draft:

<<< Proposed text >>>

7.16. Optimization of evaluation

An implementation may perform evaluation in any manner or order as long 
as the resulting response context is the same as specified by this 
specification.

None of the standard XACML functions have side effects. XACML extensions 
MAY have side effects, but an implementation and policies may not make 
any assumptions about which side effects are executed and in what order 
such execution happens. It is RECOMMENDED that no XACML extension has 
side effects.

<<< End proposed text >>>

Alternatively we could forbid side effects altogether, but that is 
probably not necessary. And it might by hard to define what a side 
effect is.

Best regards,
Erik

Hi Erik. FYI, if you look at the final section of appendix A you'll  
see that we do actually require that no extensions introduce side- 
effects. A big part of this was explicitly because of concerns over re- 
ordering operation. Of course, I don't think we say the same thing  
about policy reference/retrieval, so theoretically you could still  
introduce side-effects at the policy-combining level.

Certainly the spec is supposed to allow you to re-order many aspects  
of evaluation, though I think it does this by omission of any specific  
prohibitions rather than any explicit statement. For what it's worth,  
I think it's ok to include some comment about allowing re-ordering, as  
long as it doesn't confuse people into thinking that there's an  
obvious way that things *should* be re-ordered in practice. I think  
part of why we never called this out explicitly was to make sure that  
when people first look at XACML, they focus on the basic in-order,  
recursive model, and then start thinking about how to extend it.


seth

Hi Seth,

Thanks for pointing this out. I didn't find this section when I was 
looking for a statement like this. I think this is good enough as it is 
since it states both that no side effects are allowed and that the order 
cannot be guaranteed. So, I withdraw my proposed change.

Regards,
Erik

Seth Proctor wrote:
>
> Hi Erik. FYI, if you look at the final section of appendix A you'll 
> see that we do actually require that no extensions introduce 
> side-effects. A big part of this was explicitly because of concerns 
> over re-ordering operation. Of course, I don't think we say the same 
> thing about policy reference/retrieval, so theoretically you could 
> still introduce side-effects at the policy-combining level.
>
> Certainly the spec is supposed to allow you to re-order many aspects 
> of evaluation, though I think it does this by omission of any specific 
> prohibitions rather than any explicit statement. For what it's worth, 
> I think it's ok to include some comment about allowing re-ordering, as 
> long as it doesn't confuse people into thinking that there's an 
> obvious way that things *should* be re-ordered in practice. I think 
> part of why we never called this out explicitly was to make sure that 
> when people first look at XACML, they focus on the basic in-order, 
> recursive model, and then start thinking about how to extend it.
>
>
> seth