OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] another small time/date issue


On Tue, 12 Aug 2003, Seth Proctor wrote:

> > We say that "current-time" and friends should be provided and expected
> > to be defined, why is not it sufficient?  We can not adjust all
> > implementation clocks anyway.
> 
> 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.

Well, it goes a little deeper than that. You'd have to state that once you 
retrieve "current-*", that time is fixed, because you could conceivably 
retrieve the current-date at 23:59:59, and the current-time later at 
00:00:00 (the next day).

I really tried to argue that the request context should contain the
"access-time", and leave this concept of "current" time out of the policy.


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

Too many XACML implementation issues.

I think what Daniel might be trying to get at, is that different policies 
might be evaluated in a distributed fashion on different machines with 
different clocks, and their concept of "current" would have a 
synchronization, as well, as an accuracy problem.

This situation also makes the obvious solution problematic, as the "fetch"  
of the time at some specific point would have to be coordinated to become 
constant.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]