[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: <Advice> for NotApplicable
All, I made earlier a proposal that we extend the <Advice> so it can apply to a NotApplicable decision. I promised to send a detailed proposal, which you can find in this email. The <Advice> would be returned, like obligations, from only those policies which have been evaluated by the PDP, not including <Advice> in nested policies which are not evaluated, and only if the value of the policy matches the AppliesTo of the <Advice>. One question which was posed on the call last week was whether the <Advice> is returned if the target of a policy does not match. I suppose that this should be clarified since this is an issue which does not occuer with obligations since the FullfilOn (Permit or Deny) cannot match the policy value if the policy target does not match. I then said that I hadn't thought about it. I propose that it will be returned if the target does not match, since evaluating the target meanst that the policy has been evaluated. Another question which was asked was what happens if lots of policies in the PDP contain <Advice> for NotApplicable? Wouldn't that mean that you get lots of <Advice> each time? Yes, but if you don't want that, then don't do it. :-) The <Advice> for NotApplicable is useful inside nested policies, in cases where higher level targets have constrained the matching requests already. Here is an example where the <Advice> is useful: <PolicySet> <Target/> <Policy> <Target>It's about online banking</Target> ... </Policy> <PolicySet> <Target>it's a doctor checking a medical record</Target> <Policy> <Target>There is a patient consent for this access</Target> <Rule Effect="Permit"/> <Advice AdviceId="you-need-patient-consent" AppliesTo="NotApplicable" /> </Policy> </PolicySet> </PolicySet> Note how: - An access request about online banking never returns the nested <Advice> about patient consent since the target "it's a doctor checking a medical record" would mean that the nested policy is not evaluated. (Or, actually see below for how we must clarify the current spec in this respect.) - Note that if a doctor tries to access a medical record when he has consent, he would not get the advice since the access is permitted. - Note that if a doctor tries to access medical record when he is lacking patient consent, he gets the advice. (Assuming not other policy matches.) This is the use case one of my customers has. They are expecting that doctors forget about the consent requirements or the consent is otherwise lacking, and it would be very confusing for doctors when they are not granted access. They don't want doctors calling the helpdesk each time this happens, rather they want the application to display an error in cases like this. (And note that it is really only for this specific case they want the error message for the user, since in general it's very hard to explain why an access was not granted, since the answer is "because there is no matching policy" and there usually is not single simple attribute which is "missing".) Refactoring the policies so they return deny instead of notapplicable in this case is undesirable since it is a complication and means that that deny could override another policy which actually matches. (In other words, your choice of usable combining algorithms is reduced because of the refactoring.) One issue with obligations in general in the current spec is that the combining algorithms are ambigious about evaluation order. Now, I am not talking about that the basic combining algorithm may evaluate their child policies in any order. If that is a problem, then the user can use an ordered combining algorithm. What I mean is that none of the combining algorithms say anything about whether the PDP may continue evaluating policies even after it has reached a decision. Consider this example: <PolicySet CombiningAlg="ordered-permit-overrides"> <Policy> evalutates to permit, with Obligation 1 </Policy> <Policy> evalutates to permit, with Obligation 2 </Policy> </PolicySet> In this case a typical implementation would stop after the first policy and only return obligation 1. But I don't see anything in the spec disallowing the combining algorithm to continue evaluate the remaining policies and also including obligation 2 into the result. A related issue is that the order in which policies are evaluted with respect to child<->parent is not defined either. This is not a real problem for obligations, but for <Advice> with NotApplicable it is since it is conceivable that the PDP continues evaluating nested policies even if a policy set target does not match. Look at the medical example again: <PolicySet> <Target/> <Policy> <Target>It's about online banking</Target> ... </Policy> <PolicySet> <Target>it's a doctor checking a medical record</Target> <Policy> <Target>There is a patient consent for this access</Target> <Rule Effect="Permit"/> <Advice AdviceId="you-need-patient-consent" AppliesTo="NotApplicable" /> </Policy> </PolicySet> </PolicySet> If the target "it's a doctor checking a medical record" does not match, the PDP would typically not evaluate the contained policy and rule. But let's say it does anyway, because the spec doesn't really say that it must not. In this case it would find the Advice and include it. So if we introduce the advice with NotApplicable, then we must clarify this in the spec to make it useful. Currently the spec on the working draft on my hard drive says this in section 7.16 (it already includes the dynamic obligation expression, but otherwise it's the same as in the current published working draft): --8<-- A policy or policy set may contain one or more obligation expressions. When such a policy or policy set is evaluated, the obligation expression SHALL be evaluated to an obligation, which SHALL be passed up to the next level of evaluation (the enclosing or referencing policy, policy set or authorization decision) only if the effect of the policy or policy set being evaluated matches the value of the FulfillOn attribute of the obligation. If any of attribute assignment expression in the obligation expression evaluates to Indeterminate or a bag, the whole policy or policy set SHALL be Indeterminate. As a consequence of this procedure, no obligations SHALL be returned to the PEP if the policies or policy sets from which they are drawn are not evaluated, or if their evaluated result is "Indeterminate" or "NotApplicable", or if the decision resulting from evaluating the policy or policy set does not match the decision resulting from evaluating an enclosing policy set. If the PDP's evaluation is viewed as a tree of policy sets and policies, each of which returns "Permit" or "Deny", then the set of obligations returned by the PDP to the PEP will include only the obligations associated with those paths where the effect at each level of evaluation is the same as the effect being returned by the PDP. In situations where any lack of determinism is unacceptable, a deterministic combining algorithm, such as ordered-deny-overrides, should be used. --8<-- I propose that is changed so it is like this instead: --8<-- A policy or policy set may contain one or more obligation or advice expressions. When such a policy or policy set is evaluated, the obligation or advice expression SHALL be evaluated to an obligation or advice respectively, which SHALL be passed up to the next level of evaluation (the enclosing or referencing policy, policy set or authorization decision) only if the effect of the policy or policy set being evaluated matches the value of the FulfillOn or AppliesTo attribute of the obligation or advice respectively. If any of attribute assignment expression in the obligation or advice expression evaluates to Indeterminate or a bag, the whole policy or policy set SHALL be Indeterminate. Any obligation or advice contained directly in the policy or policy set is returned from the policy or policy set if the FulfillOn or AppliesTo. Any obligation or advice from any nested policy or policy set is returned only if the combining algorithm chooses to evaluate the nested policy or policy set. If the policy or policy set target does not match or is identerminate, then any obligations or advice from any nested policy MUST NOT be returned. As a consequence of this procedure, no obligations SHALL be returned to the PEP if the policies or policy sets from which they are drawn are not evaluated, or if their evaluated result is "Indeterminate" or "NotApplicable", or if the decision resulting from evaluating the policy or policy set does not match the decision resulting from evaluating an enclosing policy set. As a consequence of this procedure, no advice SHALL be returned to the PEP if the policies or policy sets from which they are drawn are not evaluated, or if their evaluated result is "Indeterminate", or if the decision resulting from evaluating the policy or policy set does not match the decision resulting from evaluating an enclosing policy set. If the PDP's evaluation is viewed as a tree of policy sets and policies, each of which returns "Permit", "Deny", "NotApplicable" or "Indeterminate", then the set of obligations or advice returned by the PDP to the PEP will include only the obligations or advice associated with those uninterrupted paths where the effect at each level of evaluation is the same as the effect being returned by the PDP. In situations where any lack of determinism is unacceptable, a deterministic combining algorithm, such as ordered-deny-overrides, should be used. --8<-- I don't know, but if you think it is better, we could instead make a separate section for advice, rather than try to handle advice and obligations in the same section. The sections would look very similar, but the text would be a bit simpler to read and understand. What do you prefer? Anyway, this should make the processing of <Advice> clear. (?) Best regards, Erik
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]