OASIS eXtensible Access Control Markup Language (XACML) TC

Erik,

This is definitely an area of interest to us. From our perspective, providing a broader solution would be better, such as for example, providing a decision explanation facility for both positive and negative results.

One of the real benefits of using a standard policy language is that it provides a framework for policy analysis - with decision explanation a good example. 

At some level, this is the ability to construct a kind of standard audit or proof for a XACML PDP decision. Some fragment of this audit or proof could then be returned as part of a response. 

We are facing some similar issues in the IGF project, for example, we have a situation where we want to inform a requester that user consent wasnt available. 

- prateek 


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

Hi Prateek,

Good. If the rest of the TC thinks this is interesting, I can explore 
this further. I suppose we can discuss it at the meeting this week.

BTW, regarding the question from Rich earlier (and suggestion from Bill) 
whether this could be done with obligations. I thought about it, and it 
should be possible to get a similar effect in XACML 2.0 with 
obligations, but it is a bit ugly and turns the notapplicable into a deny.

Consider the example I used:



Note that we can refactor this policy into a semantically similar policy 
set, where we can use an obligation:



I have transformed the rule into a policy so it can be "marked" with an 
obligation. And I have to make the notapplicable decision into a deny to 
be able to return the obligation, but the end result is pretty much the 
same in this use case.

Regards,
Erik


PRATEEK.MISHRA@ORACLE.COM wrote:
> Erik,
>
> This is definitely an area of interest to us. From our perspective, providing a broader solution would be better, such as for example, providing a decision explanation facility for both positive and negative results.
>
> One of the real benefits of using a standard policy language is that it provides a framework for policy analysis - with decision explanation a good example. 
>
> At some level, this is the ability to construct a kind of standard audit or proof for a XACML PDP decision. Some fragment of this audit or proof could then be returned as part of a response. 
>
> We are facing some similar issues in the IGF project, for example, we have a situation where we want to inform a requester that user consent wasnt available. 
>
> - prateek 
>
>
>   
>> 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.
>>     
>
>   

Erik Rissanen wrote:
> Good. If the rest of the TC thinks this is interesting, I can explore 
> this further. I suppose we can discuss it at the meeting this week.


For the discussion: one way to do this would be to generalize 
obligations, rather than to invent a new syntax like I did in my example.

If we allow obligations in more parts of the policy than just the 
policy/policy set level, and allow FullFillOn="NotApplicable", we can 
implement all this with obligations.

/Erik