[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] wd-19 indeterminate policy target handling
Hi Paul and TC, I think the toothpaste is out of the tube on this one: i.e. I think too much has been invested in the analysis for one member to unilaterally shut down the issue by "withdrawal". In any event, that's my opinion, but, regardless, based on yesterday's mtg, I believe there is more to be said on this issue, and hopefully we can channel it to a clean resolution. That being said, following is additional analysis I have done and some conclusions that I believe we can reach agreement on, and that I think I can describe in terms that everyone can follow (for "clarity" I will just add an "s" for the plural of "Policy"). There are 2 arguments I would like to make. Argument 1:
evaluation of Policy{DP} elements. We can then ask whether we want our combining algorithms to be subject to runtime values of Attributes that on any given evaluation can cause a Policy{DP} to become a Policy{D} or a Policy{P}, thus rendering the property of the Policy indeterminate until runtime values are plugged in. I would also suggest that it is this indeterminacy, which would cause Policys not to be comparable for "equivalence", because the Policys themselves have a built-in uncertainty depending on how one regards this property. I would also suggest that for the purpose of "equivalence" this runtime characteristic could be considered a "performance optimization", which could be a property of the Policy Engine, whereas the inherent D and P properties can be considered a Policy language characteristic independent of runtime, which could be included in an equivalence algorithm. Argument 2: There is one additional argument I would like to add for consideration. In XACML 2.0, there is a statement in section 7.10 for Policy Evaluation, which says: 'If the target value is "No-match" or “Indeterminate” then the policy value SHALL beBy comparison, in XACML 3.0, WD 19, the corresponding statement in section 7.11 has been modified to say: 'If the target value is "No-match" then the policy value SHALL beThe "Indeterminate" part of this statement has been modified to say: 'If the target value is "Indeterminate", then the policy value SHALL beTherefore, the "meaning" of the spec has been changed, because in order to select an entry in Table 7, now the rules do have to be evaluated, which is not obvious unless one does a very careful and complete reading of the changes that are being proposed. Additional Consideration: One other side effect that I think is of concern, is that if we allow the Policy property (P, D, or DP) to be subject to runtime determination then when an Indeterminate is obtained at the top of the tree, then it would be necessary to evaluate the complete subtree in order to determine what this property is. By comparison, the static property can be determined at any time by processing the tree once and recording the property for all subsequent evaluations. My Conclusions: Bottom line: my recommendation is that we define the D,P,DP property in such a way that it is a static characteristic of the Policy definition, which presumably allow it to be used in "equivalence" determinations. I would also recommend that runtime optimization be a configurable option, and it will be clear that if this option is activated, that any presumption of equivalence should be disregarded as far as runtime behavior would be concerned. Comments, suggestions welcome. Thanks, Rich On 5/6/2011 12:51 PM, Tyson, Paul H wrote: 3898C40CCD069D4F91FCD69C9EFBF096064B3D1C@txamashur004.ent.textron.com" type="cite">I withdraw my objection to the Section 7 changes made by Erik in the 3.0 core spec wd-19. I'm still concerned that the policy evaluation specification (in section 7) may cause unexpected variations in the results from two seemingly "equivalent" policies, but I need to produce some theoretical or empirical evidence to demonstrate this (or to relieve my concern). In any case, the wd-19 changes probably do not make this any better or worse. Regards, --Paul --------------------------------------------------------------------- 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]