Re: [xacml] An idea regarding decision explanation

[Erik Rissanen <erik@axiomatics.com>]

Yes, it is something similar I had in mind when I mentioned the use of 
obligations to implement it. Though I didn't think as far as combining 
the obligations, but that could perhaps be done as well. Need to think a 
bit more about that.

The main thing regarding obligations though is that currently 
obligations are allowed only in the policy or policy set. We cannot mark 
an individual TargetMatch or conditional expression with obligations.

To make it clear, maybe I should give an example of what I had in mind. 
Here's how the flight approval policy would look like:

<Policy ...>
  <Target>
    General requirements here. User must be employee, the 
resource/action has to be flight ticket purchase service use, etc.
  </Target>
  <Rule RuleId="Rule1" Effect="Permit">
    <Target/>
    <Condition>
      <Apply ...>
          Check that the user has approval for flight ticket purchase 
from the travel officer using XACML expressions here...
          <TellUser AppliesTo="Deny,NotApplible">
             You need to get approval from the travel officer.
          </TellUser>
      </Apply>
    </Condition>
  </Rule>
</Policy>

If the target matches and the Apply is evaluated, then the result will 
contain the following explanation for why access has not been allowed: 
"You need to get approval from the travel officer".

Note how the target makes sure that we don't report this if the access 
request was about some other resource/action. Also note that the fact 
that the annotation was put there by a human, the PDP can return it 
knowing that it is meaningful to the user.

This gets around the problems that in general the PDP cannot by itself 
tell what the user intended to do and and what information would be 
helpful to the user.

/Erik

Bill Parducci wrote:
> I know that I have Obligations on the Brain, but couldn't this be 
> resolved using an Obligation of say, category type [e.g.] Notify, that 
> has the message as the notification value?
>
> My thinking is that if treated this way the result could be comprised 
> combination of inputs that do not have an "explanation" and those that 
> do. Those that do would be have the Notify values combined (er, 
> aggregated ;) then passed to the end point which now can be notified 
> of possible multiple shortcomings?
>
> In this case there could be a bit more fine grained control over what 
> is communicated.
>
> What do you think?
>
> b
>
> On Oct 17, 2007, at 7:32 AM, Erik Rissanen wrote:
>
>> All,
>>
>> I have noticed that in many cases users do not seem to be happy with 
>> just a policy decision. They also want an explanation for the 
>> decision so they know what to do in case of denied access. This is 
>> perhaps also related to some of the issues you have talked about 
>> recently, Rich, I'm thinking about the missing attributes discussion.
>>
>> In general this is of course impossible to do in practice since in 
>> principle there is not much else you can do except to say "Here's the 
>> policy, and here's the request, you figure out what you are missing 
>> in order to get access."
>>
>> But I've been thinking about this. I think this could perhaps be 
>> solved in many practical cases. We can note that in general the user 
>> is probably not interested in the whole policy, but rather a small 
>> part which refers to attributes he could do something about. And in 
>> many cases policy administrators would know which parts of the 
>> policies are relevant for users. Consider the following example:
>>
>> - The full policy of an organization contains all kinds of policies 
>> with all kinds of targets, rules and conditions. One of the policies 
>> states that an employee with certain qualifications may buy flight 
>> tickets, but only if he has approval from the travel officer.
>>
>> - Assume that Alice tries to buy a flight ticket, and that she is 
>> otherwise qualified, but she does not have approval yet.
>>
>> In this case Alice is not interested in any way to know that she does 
>> not meet the conditions in the other policies, but it would help her 
>> a lot if we could tell her that she need approval since she can 
>> affect this.
>>
>> One way to solve this would be to make it possible to annotate 
>> policies in some way. The policy writers would know in this case that 
>> the approval attribute is something Alice can affect and it would be 
>> helpful for her to know that she needs to get approval and get back. 
>> The policy writers could mark the approval checking part of the 
>> policy as something that should be told to Alice if everything up to 
>> that part matches.
>>
>> I haven't worked out any details, but here is a quick idea:
>>
>> Any conditional expression or target section can contain an 
>> annotation element like this (not sure about the element name):
>>
>> <TellUser AppliesTo="Deny,NotApplible">
>> You need to get approval from the travel officer.
>> </TellUser>
>>
>> Of course the actual message could be more machine friendly, for 
>> instance containing a message code for localization, or an identifier 
>> of some kind instead of a message.
>>
>> The semantics is that if policy evaluation has reached this part of 
>> the policy, and the final decision is one of the indicated ones, the 
>> message (and perhaps a reference to the policy itself?) shall be 
>> provided to the PEP. This is a bit similar to an obligation, except 
>> that it can apply to NotApplicable as well, and it can occur in more 
>> than just policies/policy sets. (Could we implement this by allowing 
>> obligations in more places than currently?)
>>
>> This way policy writers can select those attributes/expressions which 
>> are relevant to users. And since the parts which are marked are given 
>> to the PEP only if the annotation was reached, the end result is 
>> likely to be meaningful, and not a full policy with all kinds of 
>> irrelevant stuff.
>>
>> Of course it won't solve the problem in general, but it could be 
>> quite useful in many cases and would be pretty simple to implement.
>>
>> What do you think?
>>
>> Regards,
>> Erik
>>
>