RE: [xacml] Proposed semantics for operations involving INDETERMI NATE

[Polar Humenn <polar@syr.edu>]

Didn't we go over all this stuff ad nausem a while ago?

I thought our resolution was that if you encountered something that was
considered "unavailable" in your evaluation, depending on the function
evaluates to true or false yeilding the "effect" according to the rule.

I don't see what is the benifit of ERROR in any case.  I believe we should
not be thinking operationally when specifying policy.

It is the job of the PDP to deliver Access Decisions, period, and it is
the job of XACML to specify that access decision. It is not the job of the
PDP to evalautate the consistency, availability, or correctness of that
policy.

If there is an error with the policy, quite possibly due to some transient
condition, then the PDP should deliver an Access Decision, which is one of
Permit, Deny, or Indeterminate.

Errors with the PDP should be limited to operational ones, such as
communication/invocation problems with the PDP and/or unparsability of the
output (from bad PDPs).

Cheers,
-Polar

On Mon, 22 Jul 2002, Daniel Engovatov wrote:

> I suggest the following evaluation strategy.
>
> 1) The is no distinctions made for different functions - order of evaluation
> is determined by the implementation.
>
> 2) Rule, not matching the Subject/Resource/Action head yields NOTAPPLICABLE
> (UNKNOWN) result.  No evaluation is performed.
>
> 3) All attributes mentioned in a single condition must be present/computable
> when the rule is evaluated.  The case of ordered-OR (logically - not the
> internal optimization) can be handled by defining separate rules and by rule
> recombination algorithm.
> Missing attributes or any other error condition during the rule evaluation
> yield UNDETERMINATE (ERROR) result for this particular rule.  I prefer
> "ERROR" moniker..
>
> 4) Following result recombination algorithm choices defined in the standard:
>
> 	a)ERROR precedence:  at least one rule evaluated to
> ERROR(UNDETERMINATE) returns ERROR.  Otherwise, DENY  	override is
> followed.
> 	b)DENY precedence:  if UNDETERMINATE result is reached the
> evaluation is guaranteed to proceed. If at least  	one DENY is present
> - DENY is returned.  If no deny, but at least one UNDETERMINATE -
> UNDETERMINATE is 	returned, if at least one PERMIT - permit returned,
> otherwise NOTAPPLICABLE (UNKNOWN) is returned.
> 	c)DECISION precedence:  if DENY, of PERMIT is reached, it is
> returned. If no decision, if there is 	UNDETERMINATE evaluation - it is
> returned, otherwise NOTAPPLICABLE is returned.
>
> So the precedence of results are
> 	A) ERROR - DENY - PERMIT - UNKNOWN
> 	B) DENY - ERROR - PERMIT - UNKNOWN
> 	c) DENY - PERMIT - ERROR - UNKNOWN
> 	- meaning - at least one rule evaluating to a result with higher
> precedence, returns that decision.
> 	Evaluation is guaranteed not to stop until all rules, that can yiled
> a result with higher precedence
> 	are tried (so in a case B, even if a single PERMIT is obtained, and
> no DENY - rules are evaluated to check if 	no one yield ERROR
> (UNDETERMINATE), case C is our regular DENY override recombination with
> errors ignored: but 	NOT withing the same condition (see item 3).
>
> 5) Any decision may (including ERROR/UNDERTERMINATE and
> UNKNOWN/NOTAPPLICABLE) may return advice.
>