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

Hi Erik,

I think your suggestion is on the right track that there are some attrs that
a user can do something about and would want to know about and some
that they can't and the worst thing we could is tell them about it. By 
them nothing in either case I think is less than neutral, because it may be
considered to be equivalent to an obstinate clerk who refuses to tell you
what's wrong with your application for service, but just continues to 
reject it.

My inclination is that MissingAttributeDetail contains the necessary 
but without qualification runs the risk of telling them both the helpful and
unhelpful information. Therefore, my inclination is that since the 
Policy writer
in general will know what information the user is expected to and needs to
supply, then the Policy writer should be able to write the Policy in such
a way that only the info that the Policy writer designates be included in
any MissingAttributeDetail response. Plus it would be helpful to send
an accompanying Obligation that tells the PEP that it must send this
info back to the requestor.

If that were possible with the current specs, then we should consider
documenting it a best or recommended practice. If not then we should
explore mechanisms for doing so.

One possible mechanism I believe is that Anne's WS-XACML spec
points in a direction that might be useful, although my inclination is that
the XACML structures that Anne included in the Requirements and
Capabilities elements, which amount to sending XACML Policies to
Web Service clients to process, could be improved with a possibly
optional simplified syntax which briefly identified the attribute that
is needed and any conditions that the service wants the client to know
that will be applied to the supplied attribute value. i.e. some syntax that
would identify attribute name, data type, plus a list of function codes
and limits and units that will be applied. ex.

    "<vocab:namespace>:retentionTime, xacmlxx:integer, xacmlxx:lt, 30, 

That's just a suggestion, maybe it's no better than what we have or
maybe it can be improved.


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]