<Advice> for NotApplicable

[Erik Rissanen <erik@axiomatics.com>]

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