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

[Hal Lockhart <hal.lockhart@oracle.com>]

It looks to me that you are right and this is a problem. I know that back in XACML 1.0 days, once we had decided to use mostly XML datatypes, we just looked around to see what functions useful for AC had already been defined. I don't think the thinking went any deeper.

Of course the "business hours" issue always involves figuring out weekends and holidays. (Even weekends can be different days from Saturday & Sunday, e.g. in Muslim countries.)

Hal

-----Original Message-----
From: Steven Legg [mailto:steven.legg@viewds.com] 
Sent: Tuesday, August 01, 2017 3:22 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] Is time-in-range conformant with time-equal?


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://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen
>> .org_apps_org_workgroup_portal_my-5Fworkgroups.php&d=DwICaQ&c=RoP1Yum
>> CXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=OXRy9Pk5UKmFnEkLAVgkCFoltkUS2k
>> ajg81QlTTv6pI&m=YGsei2HMO7ewD1b32nl6YdAiOWGPXKgBTFEoq1dHuHs&s=cHAK9eQ
>> gqdwdyH9qXv0Wx0GT8CdwxY5yr7zHcXoCmwM&e=


---------------------------------------------------------------------
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://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_apps_org_workgroup_portal_my-5Fworkgroups.php&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=OXRy9Pk5UKmFnEkLAVgkCFoltkUS2kajg81QlTTv6pI&m=YGsei2HMO7ewD1b32nl6YdAiOWGPXKgBTFEoq1dHuHs&s=cHAK9eQgqdwdyH9qXv0Wx0GT8CdwxY5yr7zHcXoCmwM&e=