Title: RE: [xacml] Proposed semantics for operations involving INDETERMI NATE
> Incorrect password--when passed *as one of the parameters* in the
> query--is NOT an operational error. it is reasonable therefore, to have
> defined a legitimate response reflecting the action taken. what is not
> appropriate is expecting the PEP to take action because someone changed
> the PDP's authentication information to access the PRP (preventing
> policy retrieval): that is an operational error.
>I may call that an operational error for the PDP, but not for the PEP.
>That information shouldn't even float to the PEP, as you say below. The
>PDP should decide what to do with *its* operational error and return a
>proper result to the PEP.
What's a "proper" result? Bail out? Continue with evaluating other rules?
I disagree that not being able to evaluate a possible DENY rule, due to an operational
error should be always equated to having no DENY rules at all.
That should be part of a recombination algorithm - how you prioritize -
for that you need a way to communicate such an evaluation result.
As for scalability - if you need to evaluate a zillion rules, you may want to recombine
results from several PDP, each dealing with part of the policy - say
#1, #2, #3 say N/A, as they have no rules for the subject, #4 says GRANT, #5 says ERROR, but
#5 is the one handling DENY rules. If it says N/A, I am not sure it is what we want to have..
