Thank you for the clarification.
I don't think I fully understand the
problem, and I will read your mail more carefully next week.
>> The simplest
>> way to make this change would be to change the definition of the
>> XACML time comparison functions to refer to XML Query instead
of
>> XML Schema, as the time-equal function already does.
I like this change.
>> This solution does not solve the problem
mentioned in this
>> paragraph from my original email:
A quick question:
Do you mean even though we make the
above change
we still have the problem (the change
does not solve all the problems)?
Thank you.
Satoshi Hada
IBM Tokyo Research Laboratory
mailto:
Steve Hanna <>
2003/07/18 22:40
To:
Satoshi Hada/Japan/IBM@IBMJP
cc:
Subject:
Re: [xacml] Problems with XACML and
time
Satoshi Hada wrote:
> >>This is especially odd since XACML defines time-equal to be
> >>equivalent to "the 'op:time-equal' function [XF Section
8.3.14]."
> >>This function *does* allow comparing times when one of
> >>the times has a time zone and one does not. It simply
> >>specifies that the time without a time zone should be
> >>assigned an implicit time zone (generally the local time
> >>zone).
>
> Yes, so I think every PDP should have
> an implicit time zone (the default time zone).
I expect that most PDPs do this already. Ours certainly
does.
However, this only works with time-equal. XACML defines all the
time comparison functions (like time-less-than) in terms of the
order relations defined in XML Schema, which don't allow you
to compare a time with a time zone to a time without a time zone.
> >> Can this problem be fixed by specifying
a time zone for the
> >> times specified in the policy (the AttributeValues)? That
> >> has the disadvantage of tying the policy to the specific
> >> time zone of the PDP, meaning that you can't use one policy
> >> to handle multiple time zones. In fact, you must update the
> >> policy whenever you change to Daylight Savings Time. But
set
> >> that aside. Look at policy2.xml, which adds a time zone.
>
> I agree on this disadvantage.
>
> However, I think we can specify an implicit time zone (the
> default time zone) in each PDP, not in the policy. I mean
> that all PDPs should be initialized with the default time zone
> so that both "current-time" and times with no time zone
have
> the default time zone. I think that this solves the problem.
> Or am I missing something?
This would solve one problem (the problem of having
to specify
a time zone for every explicit time in the policy), but I think
that a spec change would be required. The current language
certainly doesn't imply that this should be done. The simplest
way to make this change would be to change the definition of the
XACML time comparison functions to refer to XML Query instead of
XML Schema, as the time-equal function already does.
This solution does not solve the problem mentioned
in this
paragraph from my original email:
> Making this change does fix the problem, unless
you are in
> the Far East. If midnight GMT is between 9:00 AM and 5:00 PM
> in the PDP's time zone, then the policy always denies
> access. Surprising, eh? The reason is that the order
> relation specified by XML Schema for times says that you
> normalize the times to GMT and then compare them, with
> midnight GMT being the earliest time and 23:59:59 being
> the latest. If midnight GMT is noon local time, then the
> revised policy will only grant access is the current time
> is after 9:00 PM GMT and before 5:00 AM GMT. That can't
> ever happen.
>
> So how can this problem be addressed? If midnight GMT is
> between 9:00 AM and 5:00 PM in the PDP's time zone, you
> must rewrite the policy to say that access is granted if
> the current time is after 9:00 AM *OR* before 5:00 PM in
> the local time zone. That's pretty odd!
In my view, the best solution to this problem is the
one
described in my message:
> 2) Define a new time-in-range function that takes
three time
> arguments and returns true if the first one falls between
> the other two (on or after the second time and on or before
> the third time). If no time zone is specified for the second
> or third arguments, treat them as if they are in the time zone
> of the first argument. Then you could say
>
> time-in-range(current-time, 9:00:00, 17:00:00)
>
> to check whether the PDP-local time is between 9 AM and 5 PM
> in the PDP-local time zone (regardless of where the PDP-local
> time zone is relative to GMT).
>
> This would make it easy to solve the most common problem and
> get it right without having to understand a lot about
> times and dates, spend a lot of time changing your policy
> for different time zones, etc.
I hope this clears things up.
Thanks,
Steve
#### smime.p7s has been removed from
this note on July 18 2003 by Satoshi Hada
smime.p7s
