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

[Erik Rissanen <erik@axiomatics.com>]

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