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