Re: [xacml] Re: Combining algorithm combining orders

[Daniel Engovatov <daniel@streamdynamics.com>]

I am not sure I am following your logic.    In this case a combining  
algorithm does make a prescribed decision, and it is DENY, so clearly  
it can be made.   It is not an arbitrary choice at all - it seems  
like a very reasonable behavior for a whole lot of use cases.

What we really need is a normative way to define interchangeable  
combining algorithms - for example using some language, like XQuery.

Daniel;

On Oct 23, 2008, at 12:43 AM, Erik Rissanen wrote:

> You are right, errors should not be propagated if it can be  
> avoided, but we are discussing two particular cases where  
> propagation of the error cannot (or should not) be avoided since a  
> clear decision _cannot_ be made. Currently the combining algorithms  
> make an arbitrary choice to deny access in case of an error, which  
> is not correct if analyze how the error could affect the final  
> outcome. There are other cases where the combining algorithms  
> correctly discard errors since they can tell from the other  
> policies that the error shouldn't affect the outcome.
>
> There is no issue with giving an attacker information, since we are  
> propagating the error to the PEP, which controls the resource anyway.
>
> Regards,l
> Erik
>
> Daniel Engovatov wrote:
>>
>> On Fri, 26 Sep 2008 , at 11:52 PM, Erik Rissanen wrote:
>>
>>> Notice how the result depends on what the indeterminate could
>>> potentially be. However the current definition gives a definite  
>>> Deny in
>>> all cases. This breaks the error propagation safety of the combining
>>> algorithm.
>>
>> Error propagation safety???    Error should not be propagated if  
>> that can be avoided.   The whole point of Indeterminate value is  
>> that it can be explicitly handled by a combining algorithm, and  
>> error propagation avoided whenever possible.    Just throwing an  
>> exception all the way to the client is what we have tried to avoid.
>>
>> In all the examples result would be Deny if no error had  
>> occurred.   There is no reason to propagate errors (and to give a  
>> would be attacker any hints that some sort of disruption actually  
>> worked) when there is a clear decision.    It is somewhat  
>> different on the rule combining level, as it does not return the  
>> result to the PEP, so it is ultimately handled on the policy  
>> combining level.
>>
>> I think we have designed it this way on purpose.   I do not think  
>> it is a mistake.
>>
>> Daniel;
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/ 
>> my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php