RE: [xacml] request's attribute assertion lifetime?

[Anne Anderson <Anne.Anderson@Sun.COM>]

On 15 March, Daniel Engovatov writes: RE: [xacml] request's
attribute assertion lifetime?
 > > Frank Siebenlist wrote:
 > >"...decisions for a single time T are not very useful in practice and
 > we >rely on unspoken, implicit time-intervals for which we assume the
 > validity 
 > >of that decision."
 > 
 > Why?  That are the ONLY decisions our system, for example, is interested
 > in.   We do not control customer data, and validity of such data does
 > NOT map into simple intervals.
 > 
 > There is NO "implicit time-interval".  Decision is valid for a POINT in
 > context space.  Well defined, explicit point.  There are no extended
 > sets or intervals.  I argue that there can be no such intervals if you
 > do not know how every element in the context may depend on time (as it
 > is most likely unknown to the PDP).
 > 
 > 
 > >"The PEP actually makes use of that property to note implicitly or
 > >explicitly that the current time is still within an acceptable range
 > >compared to the time for which the decision was evaluated."
 > 
 > >In other words, we are already using time intervals for authorization
 > >decisions and enforcement ... maybe it's time to acknowledge that and
 > >formalize it instead of keeping it fuzzy and under the carpet.
 > 
 > No, we do not.  There are most definitely, absolutely, no time intervals
 > anywhere in my authorization decisions.  They are done for a specific
 > point in time.  If I want to cache it, then the data source is
 > responsible for determining whether it is OK for any dimension in the
 > context.
 > 
 > You can get the behavior you want by including the interval data as one
 > of the dimensions of this POINT in the context, as, for example, Polar
 > proposed.

I agree with Daniel.  XACML's use model has been that a PEP,
faced with an immediate access decision, consults a PDP on
whether to permit or deny that access.  If the PEP does not
include its current time in the Request, then the PDP supplies
its own current time.

The fact that a PEP can supply its own current time allows a PEP
to supply a hypothetical future (or past) time, and have the PDP
evaluate its current policies against that hypothetical time, but
this use model has not been endorsed or discussed to any extent.
I would agree with Frank that, if the PEP is supplying a
hypothetical or future time, then supplying a single point in
time is rarely going to be useful, and an interval would work
better.

I'm not saying XACML shouldn't support intervals in the future;
I'm just saying our current standard function set and use model
do not support them.  Defining a new "time interval" (or
intervals along other continua) DataType, and associated
functions, seems like a reasonable way to handle this.

As far as caching decisions about intervals in future times, I
think the fact that policies may change between the time of
evaluation and the time interval leads to more difficult
decisions than deciding how to express a request for such a
decision.  We need to know the validity period of each of the
policies involved in the evaluation.  If the policy distribution
system has a revocation mechanism, then we need to tie that in to
the cached decision.

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692