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] Making progress?

Hi Rich and All,

Great! To facilitate review, I'll write up a new working draft with 
these proposed changes and post it for review. If somebody objects, let 
me know.

Best regards,

Rich.Levinson wrote:
> Hi Erik,
> This proposal sounds good to me. Apologies for any ambiguity on my 
> preference for having the biased algorithms - it took a while for me 
> to realize that having "only" the unbiased algorithms made it 
> impossible to screen out Indeterminates and NotApplicables - I had 
> thought cleverly combining them could block things, but when I worked 
> thru the details I realized that was not possible. My sense is that 
> for the most part people will want to use unbiased, but that often 
> there will be a need to "cap off" the hierarchy w biased so that the 
> PDP actually makes the decision and doesn't leave it to the PEP. Not 
> everyone will want to do this, but I think we should make it available 
> for those who do.
> Also, I am not a strong advocate of the other 2 algorithms (5 and 6), 
> however, I found it interesting "logically" to understand where they 
> fit, especially since it appears the policy-permit-overrides in C.3 
> was intentionally the way it was to minimize the number of Indeterminates.
> It causes me to think a little more about what Indeterminate(D), (P), 
> (DP) really mean. These were defined in attachment to:
> http://lists.oasis-open.org/archives/xacml/200811/msg00028.html
> and from the perspective of the "-overrides" suffix, I think that 
> having these algorithms (5 and 6) undermines the meaning of "-overrides".
>     i.e. if we have a deny-overrides Policy and there are no denies,
>     and we are left with a permit and a potential deny
>     (Indeterminate(D)), then someone could theoretically discover that
>     they were denied by this policy, but that if they simply left out
>     an attribute, then that policy would evaluate to Indeterminate(D),
>     which would be overridden by a Permit. I know we discussed this
>     before, but I think it is worth recalling again, because it
>     appears fundamentally "wrong", at least in an algorithm named
>     "deny-overrides".
>     i.e. in prev email, I pointed out that the motivation appeared to
>     be to minimize Indeterminates, which, while it may sound like a
>     reasonable objective, the reality of it in a combining algorithm
>     really undermines the apparent intent of the algorithm.
>     i.e. deny-overrides is very weak if you can remove the impact of
>     the deny by simply submitting less information.
> Therefore, I agree that the algorithms 5,6 should not be something 
> that we recommend in the spec. It they were to be intermingled with 
> the first 4 algorithms, they could create significant confusion. If 
> someone really wants them, they can always add in a custom algorithm, 
> if their PDP supports that.
> Bottom line: I think we are in agreement w the four combining algorithms.
>     Thanks,
>     Rich
> Erik Rissanen wrote:
>> Hi Rich and all,
>> I must have misunderstood you earlier. I thought you did not want the 
>> biased algorithms. But defining them is fine for me, as long we also 
>> have the unbiased ones. I think what Daniel suggests is not what most 
>> people would want to do, since I don't think most people want to hide 
>> errors from the PEP, but if someone would like to do that, then 
>> that's up to them to define in their policy, if they can choose 
>> between biased and unbiased algorithms.
>> The four first algorithms Rich proposes are good and will cover most 
>> use cases. The first two are for regular policy combining, number 
>> three and four are useful for defining bias in a policy.
>> The last two I think are dangerous and not useful. It's dangerous to 
>> combine permits and denys when there are indeterminates which could 
>> potentially be either permit or deny (which one is dangerous depends 
>> on the algorithm). For instance, if you use deny-permit-overrides and 
>> you have a Permit and Indet{D}, then the algorithm would return a 
>> Permit, although there could have been a deny somewhere else, but 
>> this was hidden by an error. I don't see any use case for this and it 
>> could be dangerous. On the other hand, if we "fix" this problem in 
>> the algorithm, the last two become the same as the first two.
>> So, I propose that we define the following algorithms. (I like these 
>> names slightly better than the ones Rich is using.)
>> All algorithms use extended indeterminate.
>> - urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides
>> This one is not biased. Basically the same thing as the 2.0 rule 
>> combining alg.
>> - 
>> urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-overrides
>> This one is not biased. Basically the same thing as the 2.0 rule 
>> combining alg.
>> - 
>> urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-unless-permit 
>> - 
>> urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-unless-deny 
>> Best regards,
>> Erik
>> P.S. I don't think we can cover all possible combining algorithms in 
>> the standard. If we disregard order and number of policies, there are 
>> 16 possible inputs to a combining algorithm (the power set of the the 
>> set {P,D,I,NA}). For each input, the algorithm can return one out of 
>> four results. So there are a total of 4^16 different possible 
>> combining algorithms. That's about 4.3 billion variants. Correct me 
>> if I am mistaken. :-)
>> Rich.Levinson wrote:
>>> 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:
>>>    1. 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".)
>>>    2. 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:
>>>> 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 
>> ---------------------------------------------------------------------
>> 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

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