Re: [xacml] New Issue: propose carrying extended Indeterminate toResponse for PEP processing

[rich levinson <rich.levinson@oracle.com>]

Hi Erik,

I think you may be correct that it is not needed. The issues that it 
addresses are already
taken care of by the combining within the PDP, because, for example, if 
there was a P and
an IndP combined in 2.0 it would have resulted in an Ind which the PEP 
would turn to a D.
However, in 3.0, the P and IndP combine to a P which is what is returned 
and fixes the
problem.

Another variation on the problem is that if all that is returned in 
IndP, then the PEP treats
that as a D, however, that is correct since IndP is not P, and therefore 
by defn of deny-biased
PEP should be a D.

So, I will drop that issue based on current understanding.

     Thanks,
     Rich


On 5/30/2011 10:49 AM, Erik Rissanen wrote:
> Rich,
>
> Could you explain this in more detail. I don't see that this would be 
> the case.
>
> With the "bias" we can think of two things, if we allow extended 
> Indeterminate to the PEP.
>
> 1. What to do if it's N/A?
>
> 2. If there is an error and both P and D could have happened, which is 
> it?
>
> I don't think there is any use case to have a different bias in the 
> senses of 1 and 2, so let's assume they are the same, meaning that for 
> a deny biased PEP, regarding 1, the PEP will deny access. Also, if 
> there both P and D could have happened, the D is the action of the PEP.
>
> We can create the following truth table for the deny biased PEP:
>
> N/A -> D
> D -> D
> P -> P
>
> Today we also have I -> D. But let's extend that to the following:
>
> I{P} -> ?
> I{D} -> ?
> I{DP} -> ?
>
> Let's list the possible outcomes if there would not have been any errors:
>
> I{P} could have been a N/A or a P
> I{D} could have been a N/A or a D
> I{DP} could have been a N/A, a D or a P
>
> From the first truth table we get that the action of the PEP  in case 
> of a N/A would be D, so the possible actions become:
>
> I{P} leads to a possible action of a D or a P
> I{D} leads to a possible action of a D or a D
> I{DP} leads to a possible action of a D, a D or a P
>
> Since the PEP is deny biased, it will "go safe" with D over P 
> (property 2 above), leading to the following truth table:
>
> I{P} -> D
> I{D} -> D
> I{DP} -> D
>
> This is identical to a plain I -> D. So there is no value for the PEP 
> to know the extended Indeterminate value. The permit biased PEP is 
> analogous. For the "base PEP" the behavior on Indeterminate is 
> undefined anyway, so there is no value in that case either.
>
> Best regards,
> Erik
>
>
>
>
> On 2011-05-26 16:45, rich levinson wrote:
>> To TC:
>>
>> Briefly, as described in XACML analysis in ref cited in Implementor's 
>> guide:
>> http://www.oasis-open.org/committees/document.php?document_id=42300
>> http://lists.oasis-open.org/archives/xacml/201105/msg00090.html
>>
>> the same issues that drove us to create extended Indeterminate to 
>> carry D or P
>> to the Policy/PolicySet level, apply to the notion of Deny-biased and 
>> Permit-biased
>> PEPs. See sections 7.2.2 Deny-biased PEP and 7.2.3 Permit-biased PEP 
>> in WD20
>> (and earlier 3.0 versions as well)
>>
>> By simply allowing the D or P to be sent along with the Ind in the 
>> Response, then
>> 3.0 should completely address the issues raised in section 2 of the 
>> above cited ref.
>>
>>     Thanks,
>>     Rich
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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