Re: [xacml] Is time-in-range conformant with time-equal?

[Steven Legg <steven.legg@viewds.com>]

The XACML mailing list bounced my response to Bill, so this is a resend.

Steven

-------- Forwarded Message --------
Subject: Re: [xacml] Is time-in-range conformant with time-equal?
Date: Mon, 31 Jul 2017 11:59:49 +1000
From: Steven Legg <steven.legg@viewds.com>
To: Bill Parducci <bill@parducci.net>
CC: xacml@lists.oasis-open.org <xacml@lists.oasis-open.org>


Hi Bill,

On 29/07/2017 2:45 AM, Bill Parducci wrote:
> Wouldn't that require the date to answer?

If one assumes that the time-in-range function is evaluated in a manner consistent
with the time-equal (i.e., XQuery/XPath op:time-equal) function then the times are
converted to dateTime using an initial fixed date. However that is not the only
way the time-in-range function could be implemented, since the definition is not
very specific. The definition does require some manipulation of the time zones of
the three arguments, which obscures the overall intent since this differs from the
behaviour of op:time-equal, op:time-less-than and op:time-greater-than.

> Given that they are not equal means there is a range by definition, yes?

Whether the time 08:00:00+09:00 is in the inclusive range 17:00:00-06:00 to
17:00:00-06:00 (equivalently, whether 08:00:00+09:00 equals 17:00:00-06:00)
as far as time-in-range is concerned was my question, rather than a given.

My reason for asking is that I want to support XACML expressions that restrict
access to business hours in a specific time zone, e.g., 09:00:00+10:00 to
17:00:00+10:00, regardless of the date. Assume the PDP is a cloud service with
redundant copies running in different data centres possibly in different time
zones. The applications with the PEPs can be similarly dispersed and in some
cases supply explicit values for the current-time environment attribute. The
PAPs are hosted in the cloud and could be in yet other time zones.

If I use an expression like:

    time-greater-than-or-equal(current-time, 09:00:00+10:00) and
        time-less-than-or-equal(current-time, 17:00:00+10:00)

then the only way I can see for that to be reliably evaluated the way I want is
if all the PDPs, PEPs and policy authors use the same time zone offset regardless
of the time zone in which they actually reside. That's a big ask, so I've been
looking for a better solution. Though unlikely, I thought time-in-range may have
been defined to address this problem, hence my question. If time-in-range is
intended to be consistent with op:time-equal then it doesn't solve my problem and
I will create my own function, perhaps called time-in-recurring-range, that does
solve my problem. Conceptually, time-in-recurring-range would repeat the range for
each date into the past and future. In practice, it only needs to cover fixed date
minus one day, fixed date and fixed date plus one day to handle the 52 hour range
of dateTimes that op:time-equal maps to. With a function like this in the policies,
the PDPs, PEPs and policy writers can use whatever time zones they like.

Regards,
Steven

> b
>
> > On Jul 27, 2017, at 11:48 PM, Steven Legg <steven.legg@viewds.com> wrote:
> >
> >
> > The definition of the time-equal function defers to op:time-equal in "XQuery 1.0 and XPath 2.0
> > Functions and Operators", which has the particular example that 08:00:00+09:00 and
> > 17:00:00-06:00 are not equal (they are 24 hours apart when considered against a
> > fixed date). The definition of the time-in-range function isn't as precise. Is it
> > everyone's expectation that
> >
> >     time-in-range(08:00:00+09:00, 17:00:00-06:00, 17:00:00-06:00)
> >
> > would evaluate to false by similar reasoning?
> >
> > Regards,
> > Steven
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php