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] | [List Home]

Subject: Re: [xacml] An idea regarding decision explanation

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?


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


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