RE: [xacml] Validity periods in SAML Assertions

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




From: "Daniel Engovatov" <>
To: <>
Date: Thu, 5 Aug 2004 11:18:49 -0700






>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.