OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

[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

Hi Stefan,

A couple of points on your response:
  • The PolicySets and Policys do not have to be fully "evaluated". In principle, all that needs
    to be done is "check" the Effects of the Rules they contain. The idea is that a Rule with
    an Effect = "Permit", for example, has the "possibility" of generating a Permit, but it is
    unnecessary to evaluate the Rule. i.e. if the Target of a Policy is Indeterminate, then
    its Rules do not need to be evaluated. However, for a higher level policy-combining,
    it is of interest whether the Policy "could have" produced a Permit, for example.
    Again, to continue this example, if the top level PolicySet contained 2 Policys, and
    the policy-combining was "permit-overrides", then if Policy1 produced a Deny,
    and Policy 2 could produce a Permit, but was Indeterminate, then you would want
    the result to be Indeterminate. However, if Policy 2 could not produce a Permit,
    then you could let the Deny from Policy 1 stand.
  • Also, note that Indeterminate(D,P,DP) are "internal constructs" and a final result
    of Indeterminate does not carry this information to the PEP.
  • I also think that if the new combining algorithms are used, that one must assume
    that the Policy must be evaluated sufficiently (i.e. checking the Effects that the
    Rules can generate) to produce the required return values. The Policy does
    have to at least have the Target evaluated to determine Indeterminate, and there
    is no requirement that the Rules cannot also be pre-processed or post-processed
    to collect the necessary Effect information to produce the proper return value.

Again, this is proposed interpretation, as indicated earlier, there is not sufficient explicit
statements, however, the degree that implicitness can be implied may need further
discussion to remove any ambiguities, which cannot be allowed in these algorithms
if they are to produce reliable behavior.


soberhol@hsr.ch wrote:
99EECF01B5C87A498318776AB7E4A78D3639F367E9@sid00102.hsr.ch" type="cite">

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.




From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: Montag, 3. Januar 2011 19:41
To: Oberholzer Stefan (soberhol@hsr.ch)
Cc: xacml-comment@lists.oasis-open.org
Subject: Re: [xacml-comment] Extended Indeterminate values in the case of Policy Targets returning Indeterminate


Hi Stefan,

You have raised an interesting question that appears to test some of the limit cases of the
combining algorithms, which may not be explicitly represented in the spec, although,
possibly they are implicitly covered when examining the details.

I propose that the following might resolve the issue:

  • 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.


soberhol@hsr.ch wrote:

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?






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