Subject: RE: [xacml] another small time/date issue
>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.