[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Validity periods in SAML Assertions
>If the result of a rule can have no effect on the evaluation >result, regardless of the inputs to the rule, why is the rule >being evaluated? Because its condition may evaluate to false, or "X-override" recombination algorithm may ignore it. Or policy may be written to use INTERDERMINATE value for decision making. It may grant a permit when some attribute expires. Or an expired attribute value may represent an empty bag. >Likewise, if the value of some Attribute can have no effect on >the evaluation result, why is the constraint that uses the >Attribute even present? Because it may have no effect on a concrete result, but may have it on some other result. >I think both those cases are errors on the part of the policy >creation tool. I think both are very typical use cases. Context most typically will contain more data that is necessary for a concrete decision. >So, just as with computing Obligations, I think we could say that >the validity period of the XACMLAuthzDecision Assertion SHOULD >correspond to the intersection of the validity periods of all >Assertions that were actually used during the evaluation, >regardless of whether their current values made a difference or >not. This will lead to unpredictable decisions. There is no easy way to tell what attributes will be used - as recombination algorithm may short circuit evaluation in various ways. XACML guarantees a deterministic result given a static set of inputs. That's it: determining how the output of the policy will change in time is not generally possible by just looking at a subset of context: attribute assertions in this case. >But my question was, what criteria will the context handler use >to decide that an attribute assertion is invalid? Will it be the >current-dateTime in the Request or the current time at the PDP? >My proposal was to use the latter. That I agree with. I completely agree with the first part of your proposal. I just do not think that we should get into business of computing intersections etc. Decision is a decision as it was computed. It should be left to implementation do determine how this decision will be used - we just have no chance to reasonably cover all possible cases.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]