[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

*Subject*: **RE: [xacml-comment] Extended Indeterminate values in the case ofPolicy Targets returning Indeterminate**

*From*:**<soberhol@hsr.ch>***To*: <rich.levinson@oracle.com>*Date*: Tue, 4 Jan 2011 14:02:32 +0100

Hi Rich If I understand your proposed
solution correct you propose that in case of an Indeterminate Target all Rules
in a Policy must be evaluated anyway. If the combined decision would be
Indeterminate(DP) the decision stays as it would be anyway. If the decision would
be Indeterminate(P) or Permit the Policy decision is Indeterminate(P). If the
decision would be Indeterminate(D) or Deny the Policy decision is
Indeterminate(D). Intuitively I would have
also chosen this solution. But I think it allows
multiple interpretations as 7.11 also says that if the target is Indeterminate the
policies need not to be evaluated and the definition of the extended
Indeterminate value does also only say that a corresponding value may occur. So another interpretation
could also be that the existence of a Rule with the effect is already
sufficient and the Indeterminate value is set according to the existence of
such Rules. The problem I see with these
two interpretations is that a case where one interpretation leads to a Permit
where the other leads to a Deny can be created. For me the answer is
sufficient, but I think it would be great if this could be cleared in an
Erratum in a way that it isn’t a case of interpretation anymore. Regards, Stefan
Hi Stefan, - Based on section 7.11 of XACML 3.0, in order for
a Policy to evaluate to Permit or Deny,
at least one Rule must evaluate to its Effect. i.e. if a Policy contains zero Rules it must evaluate to NotApplicable or Indeterminate{noValue} (which, for practical purposes, I think is equivalent to NotApplicable, since you need an Effect to activate Obligations or Advice) - Given then that there are Rules of some sort
(either in a Policy or below in some Policy
contained in a PolicySet) following the Target, which was Indeterminate, those Rules would need to be "looked at" or "checked" to determine possible Permit or Deny outcomes that could have occurred if the Target had been Applicable. - The checking needs to follow the policy and rule
combining algorithms that process the
Indeterminate{P,D,PD}cases explicitly.
Hopefully, this helps. Hi all I have a question about the extended
Indeterminate values in the case that the Target of a Policy or PolicySet
matches to Indeterminate. I can’t find any definition
about this case in the specification. Can you please tell me which one of
the following solutions is correct? All rules appended to the Policy or PolicySet must be checked. If all of
them have the effect Permit, the indeterminate value is Indeterminate(P). If
all of them have the effect Deny, the value is Indeterminate(P). Otherwise the
value is Indeterminate(DP) It can be assumed that always a rule with a deny effect and a permit
effect is appended and therefore Indeterminate(DP) is returned All appended Policies must be evaluated. If all of them are
Indeterminate(P) or a Permit, Indeterminate(P) is returned. If all of them have
the effect Deny or Indeterminate(D) Indeterminate(D) is returned. If at least
one is Deny or Indeterminate(D) and another one is Permit or Indeterminate(P)
Indeterminate(DP) is returned. Indeterminate with no value should be returned If it is the case that an
Indeterminate is returned I can’t see a definition how this is combined
in the Permit-overrides and Deny-overrides algorithms. Can
anybody help me in this case? Regards, Stefan |

**Follow-Ups**:**Re: [xacml-comment] Extended Indeterminate values in the case ofPolicy Targets returning Indeterminate***From:*"Rich.Levinson" <rich.levinson@oracle.com>

**References**:**Extended Indeterminate values in the case of Policy Targetsreturning Indeterminate***From:*<soberhol@hsr.ch>

**Re: [xacml-comment] Extended Indeterminate values in the case ofPolicy Targets returning Indeterminate***From:*"Rich.Levinson" <rich.levinson@oracle.com>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]