RE: [xacml] another small time/date issue

["Daniel Engovatov" <dengovatov@bea.com>]

>We already require these values be provided, so there's no
>complication in keeping them constant, and this certainly isn't out of
>scope of XACML since it defines how a standard attribute should be
>handled during policy evaluation. This has nothing to do with
geographic
>location or accuracy.

But what if the evaluation is distributed?  It should be possible.
Also, it may be a problem to keep them constant - PDP may not have the
caching of data, and PIP may not be aware of the duration of the
evaluation session.
I do not think we should specify the architecture of PIP and for data
paths provided from the virtual context - things like caching, sessions
etc. are too specific to a particular implementation.
Yes, that means that a time-based policy is not 100% portable, but
nothing that rely on an external information source is 100% portable.
For 100% portability this attribute has to be specified in the request,
and is such a case we already state (do we ?) that it will be constant
for the duration of the evaluation, and no further clarifications are
needed.

>If you refer to current-time twice in a policy where the value is being
>supplied by the PDP, one implementation might return two slightly
>different values while another might return the same value twice. This
>is not likely to be a huge problem, but it does represent different
>behavior across different applications, and it can be addressed without
>too much difficulty.

That's what I am not sure about.  Why XACML should address the value of
time?  If it is the accuracy that you are worried about - then we have
to specify the expected accuracy.

>I'm not sure what adjusting clocks has to do with this...

If your PDPs are on different machines, they may have different clocks.
I think we should not be in the business of synchronizing them.

Daniel.