MHonArc v2.5.0b2 -->
xacml message
[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]