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] Proposed functional enhancement - Optional return of policy ids of policies applicable to request

Hal Lockhart wrote:
> This is something we talked about a long time ago and I sort of forgot
> about it. I am now proposing we add it to 3.0. If everybody is ok with the
> idea, I will propose specific text.
> As a feature for administration, debugging, what if processing and user
> performance improvement I think it would be convenient to be able to ask
> the PDP to return a list of all the policy Ids of the policies which were
> found to be applicable during the evaluation of a particular decision.
> Note that because of optimization, this list might not contain all the
> policies applicable to the request (if the PDP got the answer w/o
> evaluating them all). This implies that two different implementations
> might return different results.

I whole-heartedly agree with adding this feature.

Since the objective is to describe what actually was evaluated to
reach an outcome, I do not see any problem in two implementations
returning different responses if the rule set(s) was(were) written
to be nondeterministic.

For efficient implementation, "short circuit" evaluation should
be allowed where possible -- mere logging feature should not
force you to the expense of full evaluation.

Also, when folks optimize the rule sets into their internal
representations, it is common that mapping to original rules
gets a little blurred. I think we should view this policy id log
as an analog to C compiler reporting yacc source line numbers: there
is a connection, but due to optimization it is not guaranteed
to be linear. The log output would be for consumption by
human expert who understand the issues, and the tools they use.

> Basically this would require a flag in the request to indicate that the
> Ids are requested and an element in the response to contain the list. The
> proposal is to do this in core, not just in the SAML Req/Resp.
> Implementation would be optional. However, in order to do reduction, you
> need to track this anyway.

Seems straight forward. Any chance of adding this as optional
to XACML 2.0 as well?


> Hal

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