Hi Erik, and all,
I have some concerns about the proposed resolution. In particular,
dis-allowing the biased algorithms (the existing XACML 2.0
policy-combining algorithm, deny-overrides, section C.1, is biased,
explicitly because of lines 5225-5228 (if Indeterminate return Deny))
we are essentially changing what, according to Daniel, was planned
functionality:
http://lists.oasis-open.org/archives/xacml/200810/msg00027.html
"The whole point of Indeterminate value is that it can be
explicitly handled by a combining algorithm, and error propagation
avoided whenever possible. Just throwing an exception all the way to
the client is what we have tried to avoid."
In all the discussion that followed that, from my perspective, we were
trying to find a rationale for determining what the "correct" set of
combining algorithms should be. In the process, we uncovered two
fundamental characteristics of the existing algorithms:
- There is an implicit "bias" property that was exhibited in policy
deny-overrides (C.1), that did not have a corresponding representation
policy permit-overrides (C.3). (and it also appeared that C.3 had a
mistake, because a Deny was given precedence over Indeterminate in a
permit-overrides algorithm, which appeared to ignore the fact that the
Indeterminate is a potential-permit. Based on the text preceding the
p-code, and Daniel's comment above, this may also have been intended,
with the notion that any definitive decision is preferable to
Indeterminate, however it appears to be a 3rd variation to the notion
of "overrides".)
- There is an implicit "extended" property (probably need a better
term) that was inherent in the rule-combining algorithms that was
screened out in the policy-combining algorithms. This property reflects
the "half-boolean" nature of a Rule, and also possibly a collection of
Rules, and also the logical property propagates up to the Policy and
PolicySet levels as well. However, the property was only processed by
rule-combining algorithms, which accounts for the difference between
the rule-combining and policy-combining algorithms, which effectively
discards potentially useful information.
The suggestion I made at the end of:
http://lists.oasis-open.org/archives/xacml/200811/msg00037.html
which was to have 2 biased and 2 un-biased extended algorithms enables
all of the functional issues above to be addressed, except possibly the
"3rd variation of overrides", which could possibly add 2 more
(definitive-decision overrides) algorithms if that is a desired option.
The point is that the existing algorithms represent a particular
logical subset of the possible logical algorithms of the implicit
domains that represent a 3x2 matrix (3 override options: permit,deny
and definitive-decision, and 2 bias options: unbiased, biased).
In addition, the existing algorithms, do not process all the
information (policy combining drops the extended Indeterminate
property).
The following proposal is 6 algorithms that should cover all the cases
above, where these algorithms can be used at both the policy and rule
levels:
- extended deny-overrides (e.g. C.1 rule)
- extended permit-overrides (e.g. C.3 rule)
- extended biased deny-overrides (deny unless explicitly permitted)
(e.g. C.1 policy)
- extended biased permit-overrides (permit unless explicitly denied)
- extended deny-permit-overrides (indeterminate only if no deny or
permit)
- extended permit-deny-overrides (indeterminate only if no permit
or deny) (e.g C.3 policy)
I think the above list at least makes explicit the logical options that
are implicitly contained in the existing algorithms. The fact that they
are all prefixed by "extended" means that the nature of Indeterminates
is logically preserved, although the 2 explicitly "biased" algorithms
remove this property by removing Indeterminates.
With the above context in mind, my inclination is that the existing
algorithms are purposefully aimed at reducing the return of
Indeterminates, while at the same time attempting to preserve some
aspects of the half-boolean nature of an Indeterminate from a single
Rule and the potential half-boolean nature of a collection of Rules
within a Policy. (However, the existing algorithms do not take into
account the potential half-boolean nature of a Policy, PolicySet, or
collections of Policies and PolicySets.)
Therefore, I am very reluctant to agree that we should only include
unbiased algorithms.
One final point to the comment in Erik's email:
"Currently this means that policies have to be refactored
so that all such rules are isolated in their own policy since rules
cannot contain obligations directly. This is a bit of nuisance to do."
I do not believe that with the existing algorithms that policies "can"
be refactored to allow the rules to appear in their own policies,
because the rules are subject to rule combining algorithms which
contain logic not available in the policy combining algorithms. It is
only by using the extended combining algorithms that this refactoring
is possible.
Thanks,
Rich
Erik Rissanen wrote:
493D0C7C.3060807@axiomatics.com" type="cite">Hi
Rich, and all,
It was noted during the discussion that it may be the case that one
writes a number of rules with conditions, such that if those conditions
trigger, there should be an obligation. Currently this means that
policies have to be refactored so that all such rules are isolated in
their own policy since rules cannot contain obligations directly. This
is a bit of nuisance to do.
There was some discussion that there is really no fundamental reason to
allow obligations at the rule level. I have thought the same thing
previously, and I think it would be a good idea to allow obligations in
rules as well. At first I was opposed to the change since we have a
feature freeze and we should focus on closing issues rather than
opening new ones. But I think this is a minor change which could be
made.
TC: what is the general opinion on this? Should we change the schema so
rules can contain obligations as well? It would be good if I could get
a general indication of what we want to decide, and I could prepare a
draft for review this week already, so we could close this issue on the
next call already. Otherwise we will make the decision on the next
call, and I edit the daft after that and the final closing of the issue
is pushed past the holidays, delaying everything by a month or so.
Also, could I get some kind of indication on what we want to do
regarding policy combination? After the discussions Rich and I have
had, I propose the following, which I think Rich and I at least would
agree on:
- The regular XACML combining algorithms will not be biased.
- We make use of the "extended indeterminate" to have better error
handling capability at the policy combining level. This also makes the
rule and policy combining algorithms symmetric.
- We do not specify biased variants of the combining algorithms?
TC: Could I get a rough indication on what people feel on this issue?
If so I could finish a working draft this week which can be reviewed
for CD status on the next meeting.
Best regards,
Erik
Rich.Levinson wrote:
Hi Erik,
Unfortunately I missed the meeting this morning, however, Hal filled me
in on some details. In particular, Hal mentioned that in the Boeing
presentation that there was indicated a requirement for having
Obligations available at the Rule level, while they are currently
available only at the Policy level. This was also mentioned in today's
minutes, but it is not clear from the minutes or a quick read of the
presentation referred to in the minutes what the exact requirements
are:
http://lists.oasis-open.org/archives/xacml/200812/msg00008.html
In any event, based on the partial information, I will take a stab at a
possible means to address this issue.
One aspect of the discussion on issue 66 is that we agreed there is
essentially an "extra layer" in the PolicySet/Policy/Rule hierarchy,
which can effectively be removed using the uniform extended combining
algorithms we discussed in earlier emails:
http://lists.oasis-open.org/archives/xacml/200811/msg00040.html
As a result of this uniformity, there is no longer any compelling
reason to have more than one Rule in a Policy. i.e. if you have n Rules
in a Policy and decide you want "1-rule" Policies, then you can simply
change the parent Policy to a PolicySet and replace each Rule with a
Policy containing only that Rule. This will enable one to effectively
apply Obligations at the Rule level since all you need to do is apply
the Obligations to the Policy containing the single Rule.
I am not sure if that addresses the requirements as stated at today's
meeting, but would be interested to know if it does, or if there are
additional requirements that this would not cover.
Thanks,
Rich
Erik Rissanen wrote:
All,
Could we get some more discussion on the open issues on the list so I
could write up a tentative working draft in good time before the next
meeting?
Having long technical discussions on the calls only is very
inefficient. During the call today we spent 50 minutes discussing a
single issue, and we had an almost as long discussion on the same issue
last time. It would be much better if we could have more discussion on
the list so we can make more decisions on the TC calls. Going like this
means that we have many more months before we have a committee draft.
If I can get a rough direction on the following issues, I can edit the
specs for review before the next meeting so we can hopefully approve
them on the next call. Otherwise the whole thing is going to slip into
the holidays and get delayed even more.
- Issue #66: policy combining. Should we fix the combining algorithm
bias and should we extend the indeterminate?
- The small issues in the SAML profile. Can I get feedback on them? Hal
has promised to fix the wording of the returned request in the SAML
XACML Authz response.
- I also propose that we extend the schema so a Rule can contain
obligations in the same way as Policies/PolicySets. This means that we
avoid the need of rewriting rules into policies in some cases.
Best regards,
Erik
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|