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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


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


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





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


Powered by eList eXpress LLC